Asynchronous channel access control of a wireless system

ABSTRACT

This disclosure provides systems, methods and apparatus for asynchronous channel access control of a wireless system. In some aspects, a device may adjust the priority of one or more PPDUs and may perform other operations to ensure control of a wireless medium at certain times while still allowing for other devices to communicate on the wireless medium. For example, the device may adjust a backoff counter or one or more EDCA parameters to ensure obtaining control of the wireless medium to transmit a first PPDU of an application file. For one or more subsequent PPDUs of the application file, the device may again adjust a backoff counter or one or more EDCA parameters to allow other devices to obtain control of the wireless medium in certain scenarios (such as a second device to provide information back to the device or to otherwise transmit using the shared wireless medium).

The present application for Patent is a Continuation of U.S. patentapplication Ser. No. 17/188,165 entitled “ASYNCHRONOUS CHANNEL ACCESSCONTROL OF A WIRELESS SYSTEM” filed Mar. 1, 2021, pending, and assignedto the assignee hereof and hereby expressly incorporated by referenceherein.

TECHNICAL FIELD Description of the Related Technology

A wireless local area network (WLAN) may be formed by one or more accesspoints (APs) that provide a shared wireless communication medium for useby a number of client devices also referred to as stations (STAs). Thebasic building block of a WLAN conforming to the Institute of Electricaland Electronics Engineers (IEEE) 802.11 family of standards is a BasicService Set (BSS), which is managed by an AP. Each BSS is identified bya Basic Service Set Identifier (BSSID) that is advertised by the AP. AnAP periodically broadcasts beacon frames to enable any STAs withinwireless range of the AP to establish or maintain a communication linkwith the WLAN.

Some wireless communication devices may be associated with low-latencytraffic (such as gaming or extended reality (XR) traffic) having strictend-to-end latency, packet loss, and throughput requirements. It isdesirable for WLANs to ensure that such low-latency traffic can behandled without violating their respective latency and packet lossrequirements.

SUMMARY

The systems, methods and devices of this disclosure each have severalinnovative aspects, no single one of which is solely responsible for thedesirable attributes disclosed herein.

One innovative aspect of the subject matter described in this disclosurecan be implemented as a method for wireless communication. In someimplementations, the method may be performed by a wireless communicationdevice, and may include obtaining control of a wireless medium. Controlof the wireless medium is associated with a first priority oftransmitting, over the wireless medium, a first physical layer protocoldata unit (PPDU) of an application file from the wireless communicationdevice to a second device, and the first priority is different than asecond priority of transmitting data from the second device to thewireless communication device over the wireless medium. The method alsomay include providing the first PPDU to the second device. The methodalso may include providing one or more subsequent PPDUs of theapplication file to the second device. Providing the one or moresubsequent PPDUs is associated with a third priority of transmitting theone or more subsequent PPDUs over the wireless medium.

Another innovative aspect of the subject matter described in thisdisclosure can be implemented in a wireless communication device. Thewireless communication device includes a processing system and aninterface. The interface is configured to obtain control of a wirelessmedium. Control of the wireless medium is associated with a firstpriority of transmitting, over the wireless medium, a first PPDU of anapplication file from the wireless communication device to a seconddevice, and the first priority is different than a second priority oftransmitting data from the second device to the wireless communicationdevice over the wireless medium. The interface also is configured toprovide the first PPDU to the second device and provide one or moresubsequent PPDUs of the application file to the second device. Providingthe one or more subsequent PPDUs is associated with a third priority oftransmitting the one or more subsequent PPDUs over the wireless medium.

Another innovative aspect of the subject matter described in thisdisclosure can be implemented as another method for wirelesscommunication. In some implementations, the method may be performed by awireless communication device, and may include obtaining a first PPDU ofan application file from an AP over a wireless medium. The AP obtainscontrol of the wireless medium. Control of the wireless medium isassociated with a first priority of transmitting the first PPDU over thewireless medium, and the first priority is different than a secondpriority of transmitting data from the wireless communication device tothe AP over the wireless medium. The method also may include obtainingone or more subsequent PPDUs of the application file from the AP.Obtaining the one or more subsequent PPDUs is associated with a thirdpriority of transmitting the one or more subsequent PPDUs over thewireless medium.

Another innovative aspect of the subject matter described in thisdisclosure can be implemented in another wireless communication device.The wireless communication device includes a processing system and aninterface. The interface is configured to obtain a first PPDU of anapplication file from an AP over a wireless medium. The AP obtainscontrol of the wireless medium. Control of the wireless medium isassociated with a first priority of transmitting the first PPDU over thewireless medium, and the first priority is different than a secondpriority of transmitting data from the wireless communication device tothe AP over the wireless medium. The interface also is configured toobtain one or more subsequent PPDUs of the application file from the AP.Obtaining the one or more subsequent PPDUs is associated with a thirdpriority of transmitting the one or more subsequent PPDUs over thewireless medium.

Another innovative aspect of the subject matter described in thisdisclosure can be implemented as another method for wirelesscommunication. In some implementations, the method may be performed by adevice, and may include obtaining, from a second device, uplink (UL)data over a wireless medium and providing, to the second device,downlink (DL) data including PPDUs over the wireless medium. One or morePPDUs are provided to the second device during a current target waketime (TWT) window, and a beginning of the current TWT window isassociated with one of: when a first PPDU of the one or more PPDUs isprovided to the second device; or when the first PPDU is provided froman application layer to a media access control layer (MAC) of thedevice.

Another innovative aspect of the subject matter described in thisdisclosure can be implemented in a device. The device includes aprocessing system and an interface. The interface is configured toobtain, from a second device, UL data over a wireless medium andprovide, to the second device, DL data including PPDUs over the wirelessmedium. One or more PPDUs are provided to the second device during acurrent TWT window, and a beginning of the current TWT window isassociated with one of: when a first PPDU of the one or more PPDUs isprovided to the second device; or when the first PPDU is provided froman application layer to a MAC of the device.

Another innovative aspect of the subject matter described in thisdisclosure can be implemented as another method for wirelesscommunication. In some implementations, the method may be performed by adevice, and may include providing UL data to a second device over awireless medium and obtaining, from the second device, DL data includingPPDUs over the wireless medium. One or more PPDUs are obtained from thesecond device during a current TWT window, and a beginning of thecurrent TWT window is associated with one of: when a first PPDU of theone or more PPDUs is provided by the second device; or when the firstPPDU is provided from an application layer to a MAC of the seconddevice.

Another innovative aspect of the subject matter described in thisdisclosure can be implemented in a device. The device includes aprocessing system and an interface. The interface is configured toprovide UL data to a second device over a wireless medium and obtain,from the second device, DL data including PPDUs over the wirelessmedium. One or more PPDUs are obtained from the second device during acurrent TWT window, and a beginning of the current TWT window isassociated with one of: when a first PPDU of the one or more PPDUs isprovided by the second device; or when the first PPDU is provided froman application layer to a MAC of the second device.

Another innovative aspect of the subject matter described in thisdisclosure can be implemented as another method for wirelesscommunication. In some implementations, the method may be performed by adevice, and may include rendering a plurality of video frames to beprovided to a second device, splitting each video frame of the pluralityof video frames into a plurality of video slices, and, for each videoslice of the plurality of video slices, generating a plurality of PPDUsto include the video slice. Each PPDU includes one or more media accesscontrol layer (MAC) service data units (MSDUs) associated with the videoslice, and the video slice is identified by a port number and adifferentiated services field codepoint (DSCP) value included in eachMSDU of the plurality of PPDU. The method also includes, for each videoslice of the plurality of video slices, queuing the MSDUs fortransmission to the second device.

Another innovative aspect of the subject matter described in thisdisclosure can be implemented in a device. The device includes aprocessing system and an interface. The processing system is configuredto render a plurality of video frames to be provided to a second device,split each video frame of the plurality of video frames into a pluralityof video slices, and, for each video slice of the plurality of videoslices, generate a plurality of PPDUs to include the video slice. EachPPDU includes one or more MSDUs associated with the video slice, and thevideo slice is identified by a port number and a DSCP value included ineach MSDU of the plurality of PPDU. The processing system also isconfigured to, for each video slice of the plurality of video slices,queue the MSDUs for transmission to the second device.

Another innovative aspect of the subject matter described in thisdisclosure can be implemented as another method for wirelesscommunication. In some implementations, the method may be performed by adevice, and may include obtaining, from a second device, one or morePPDUs associated with a video frame. The second device renders aplurality of video frames to be provided to the device, and the seconddevice splits each video frame of the plurality of video frames into aplurality of video slices. For each video slice of the plurality ofvideo slices, the second device generates a plurality of PPDUs toinclude the video slice. Each PPDU includes one or more MSDUs associatedwith the video slice, and the video slice is identified by a port numberand a DSCP value included in each MSDU of the plurality of PPDU. Foreach video slice of the plurality of video slices, the second devicequeues the MSDUs for transmission to the device.

Another innovative aspect of the subject matter described in thisdisclosure can be implemented in a device. The device includes aprocessing system and an interface. The interface is configured toobtain, from a second device, one or more PPDUs associated with a videoframe. The second device renders a plurality of video frames to beprovided to the device, and the second device splits each video frame ofthe plurality of video frames into a plurality of video slices. For eachvideo slice of the plurality of video slices, the second devicegenerates a plurality of PPDUs to include the video slice. Each PPDUincludes one or more MSDUs associated with the video slice, and thevideo slice is identified by a port number and a DSCP value included ineach MSDU of the plurality of PPDU. For each video slice of theplurality of video slices, the second device queues the MSDUs fortransmission to the device.

Another innovative aspect of the subject matter described in thisdisclosure can be implemented as another method for wirelesscommunication. In some implementations, the method may be performed by adevice, and may include attempting to provide a plurality of PPDUsassociated with one or more video frames of an XR experience to a seconddevice and measuring one or more of a PPDU transmission latencyassociated with attempting to provide the plurality of PPDUs or a PPDUtransmission drop associated with attempting to provide the plurality ofPPDUs. One or more parameters of the XR experience are adjusted andassociated with one or more of the measurements.

Another innovative aspect of the subject matter described in thisdisclosure can be implemented in a device. The device includes aprocessing system and an interface. The interface is configured toattempt to provide a plurality of PPDUs associated with one or morevideo frames of the XR experience to a second device. The processingsystem is configured to measure one or more of a PPDU transmissionlatency associated with attempting to provide the plurality of PPDUs ora PPDU transmission drop associated with attempting to provide theplurality of PPDUs. One or more parameters of the XR experience areadjusted and associated with one or more of the measurements.

Another innovative aspect of the subject matter described in thisdisclosure can be implemented as another method for wirelesscommunication. In some implementations, the method may be performed by adevice, and may include attempting to provide a plurality of pose dataframes associated with one or more video frames of an XR experience to asecond device and measuring one or more of a pose data frametransmission latency associated with attempting to provide the pluralityof pose data frames or a pose data frame transmission drop associatedwith attempting to provide the plurality of pose data frames. One ormore parameters of the XR experience are adjusted and associated withone or more of the measurements.

Another innovative aspect of the subject matter described in thisdisclosure can be implemented in a device. The device includes aprocessing system and an interface. The interface is configured toattempt to provide a plurality of pose data frames associated with oneor more video frames of an XR experience to a second device. Processingsystem is configured to measure one or more of a pose data frametransmission latency associated with attempting to provide the pluralityof pose data frames or a pose data frame transmission drop associatedwith attempting to provide the plurality of pose data frames. One ormore parameters of the XR experience are adjusted and associated withone or more of the measurements.

Another innovative aspect of the subject matter described in thisdisclosure can be implemented as another method for wirelesscommunication. In some implementations, the method may be performed by awireless communication device, and may include communicating with afirst device over a first wireless link and communicating with a seconddevice over a second wireless link. The wireless communication devicecommunicates concurrently with the first device and the second deviceusing one of multi-link operation (MLO) techniques or a TWT mode, andthe wireless communication device is configured to give preference tocommunications on the second wireless link versus communications on thefirst wireless link.

Another innovative aspect of the subject matter described in thisdisclosure can be implemented in a wireless communication device. Thewireless communication device includes a processing system and aninterface. The interface is configured to communicate with a firstdevice over a first wireless link and communicate with a second deviceover a second wireless link. The wireless communication devicecommunicates concurrently with the first device and the second deviceusing one of MLO techniques or a TWT mode, and the wirelesscommunication device is configured to give preference to communicationson the second wireless link versus communications on the first wirelesslink.

Details of one or more implementations of the subject matter describedin this disclosure are set forth in the accompanying drawings and thedescription below. Other features, aspects, and advantages will becomeapparent from the description, the drawings, and the claims. Note thatthe relative dimensions of the following figures may not be drawn toscale.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A shows a pictorial diagram of an example wireless communicationnetwork.

FIG. 1B shows a pictorial diagram of a group of example devices toprovide an extended reality (XR) experience.

FIG. 2A shows an example protocol data unit (PDU) usable forcommunications between wireless communication devices.

FIG. 2B shows an example field in the PDU of FIG. 2A.

FIG. 3A shows another example PDU usable for communications betweenwireless communication devices.

FIG. 3B shows another example PDU usable for communications betweenwireless communication devices.

FIG. 4 shows an example physical layer convergence protocol (PLCP)protocol data unit (PPDU) usable for communications between wirelesscommunication devices.

FIG. 5 shows a block diagram of an example wireless communicationdevice.

FIG. 6A shows a block diagram of an example access point (AP).

FIG. 6B shows a block diagram of an example station (STA).

FIG. 7 shows a sequence diagram illustrating examplemotion-to-render-to-photon (M2R2P) operations.

FIG. 8 shows a flowchart illustrating an example process forasynchronous channel access control according to some implementations.

FIG. 9 shows a flowchart illustrating an example process forasynchronous channel access control according to some implementations.

FIG. 10 shows a sequence diagram illustrating example transmissionsbetween devices for an XR experience.

FIG. 11 shows a flowchart illustrating an example process forsynchronous channel access control based on a target wake time (TWT)session according to some implementations.

FIG. 12 shows a flowchart illustrating an example process forsynchronous channel access control based on a TWT session according tosome implementations.

FIG. 13 shows a sequence diagram illustrating example timings of posedata frames and rendering of video frames associated with a motion torender (M2R) latency.

FIG. 14 shows a sequence diagram illustrating example timings of posedata frames and rendering of video frames associated with a M2R latency.

FIG. 15A shows a block diagram illustrating an example of synchronizingthe clocks of the render device and the display device.

FIG. 15B shows a block diagram illustrating an example of synchronizingthe clocks of the render device and the display device.

FIG. 15C shows a block diagram illustrating an example of synchronizingthe clocks of the render device and the display device.

FIG. 16 shows a flowchart illustrating an example process for managingdata for transmission according to some implementations.

FIG. 17 shows a flowchart illustrating an example process for managingdata for transmission according to some implementations.

FIG. 18 shows a block diagram illustrating an example of generatingqueues for one or more video frames.

FIG. 19 shows a flowchart illustrating an example process for generatingfeedback according to some implementations.

FIG. 20 shows a flowchart illustrating an example process for generatingfeedback according to some implementations.

FIG. 21 shows a block diagram of an example control field.

FIG. 22 shows a flowchart illustrating an example process for supportingconcurrent wireless links with multiple devices.

FIG. 23 shows a sequence diagram illustrating example timings of XRactivity and wireless activity with an AP.

Like reference numbers and designations in the various drawings indicatelike elements.

DETAILED DESCRIPTION

The following description is directed to certain implementations for thepurposes of describing innovative aspects of this disclosure. However, aperson having ordinary skill in the art will readily recognize that theteachings herein can be applied in a multitude of different ways. Thedescribed implementations can be implemented in any device, system, ornetwork that is capable of transmitting and receiving radio frequency(RF) signals according to one or more of the Institute of Electrical andElectronics Engineers (IEEE) 802.11 standards, the IEEE 802.15standards, the Bluetooth® standards as defined by the Bluetooth SpecialInterest Group (SIG), or the Long Term Evolution (LTE), 3G, 4G or 5G(New Radio (NR)) standards promulgated by the 3rd Generation PartnershipProject (3GPP), among others. The described implementations can beimplemented in any device, system or network that is capable oftransmitting and receiving RF signals according to one or more of thefollowing technologies or techniques: code division multiple access(CDMA), time division multiple access (TDMA), frequency divisionmultiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA(SC-FDMA), single-user (SU) multiple-input multiple-output (MIMO), andmulti-user (MU) MIMO. The described implementations also can beimplemented using other wireless communication protocols or RF signalssuitable for use in one or more of a wireless personal area network(WPAN), a wireless local area network (WLAN), a wireless wide areanetwork (WWAN), or an internet of things (IOT) network.

Various implementations relate generally to an architecture to providean extended reality (XR) experience to a user. Wireless data associatedwith an XR experience generally have strict latency and packet lossrestrictions to prevent reduction of the user experience. For example,packets for video frames or other data (including audio, hapticcommands, and so on) must be rendered, delivered to a displaying device(such as a head mounted display (HMD), a wearables display, or othersuch wireless or wired display devices), and displayed at near realtime. In addition, sensor information from the displaying device orother device on the user (such as measurements from an inertialmeasurement unit (IMU)) is used for rendering, which further complicatesthe latency requirements. Typical wireless systems are not designedunder such restrictions for rendering, delivery, and displaying of datato ensure a minimum frame rate and to prevent synchronization issues,studder, or lag for an XR experience.

Some implementations more specifically relate to asynchronous channelaccess control of a wireless system for devices providing an XRexperience. In accordance with some aspects of the present disclosure, adevice may adjust the priority of one or more physical layer (PHY)convergence protocol (PLCP) data units (PPDUs) and may perform otheroperations to ensure control of the wireless medium at certain timeswhile still allowing for other devices to communicate on the wirelessmedium. For example, the device may adjust a backoff counter or adjustone or more enhanced distributed channel access (EDCA) parameters toensure obtaining control of the wireless medium to transmit a first PPDUof an application file. For one or more subsequent PPDUs of theapplication file, the device may again adjust a backoff counter oradjust one or more EDCA parameters to allow other devices to obtaincontrol of the wireless medium in certain scenarios (such as for adisplay device to provide information back to the device or for anotherdevice to transmit using the shared wireless medium).

Particular implementations can be implemented to realize one or more ofthe following potential advantages. The render device ensuring controlof the wireless medium may allow the render device to meet the latencyrequirements for the XR experience. The render device allowing others totransmit on the wireless medium may allow the wireless medium to beshared in an environment with multiple devices in a basic service set(BSS) or with multiple overlapping basic service sets (OBSSs). Therender device also may be configured to allow the display device toprovide sensor measurement and other information to the render devicefor rendering to meet latency and other requirements for the XRexperience.

Some implementations more specifically relate to synchronous channelaccess control of a wireless system for devices providing an XRexperience. In accordance with some aspects of the present disclosure, arender device may use a target wake time (TWT) session to communicatewith the display device during one or more TWT service periods (alsoreferred to as windows). The TWT session may be configured and managedto ensure control of the wireless medium to meet latency requirements orother requirements for the XR experience. Use of TWT windows allowsother devices to use the wireless medium outside of the TWT windows.

Particular implementations can be implemented to realize one or more ofthe following potential advantages. The render device ensuring controlof the wireless medium via use of TWT may allow the render device tomeet the latency requirements for the XR experience. The render deviceallowing others to transmit on the wireless medium may allow thewireless medium to be shared in an environment with multiple devices.

Some implementations more specifically relate to application based datatransport mechanisms for wireless communications in a synchronouschannel control wireless system for an XR experience. In accordance withsome aspects of the present disclosure, a render device may manageapplication data to be transmitted, and the display device may manageapplication data received to ensure that latency requirements of the XRexperience are met. Management of the data includes generating, queuing,and identifying MSDUs for different video slices to be transmitted,flushing queues when appropriate, and indicating flushing to the displaydevice. Management at the display device may be flushing a reorder (REO)queue or otherwise managing the REO queue receiving the MSDUs from therender device.

Particular implementations can be implemented to realize one or more ofthe following potential advantages. Management of the queues (includinggenerating and flushing the queues) may ensure that latency requirementsof the XR experience are met. Management of the queues also may ensurethe removal of stale data that may increase a communication latencybetween the render device and the display device.

Some implementations more specifically relate to providing feedback andadapting an XR experience based on the feedback. In accordance with someaspects of the present disclosure, a render device may attempt totransmit PPDUs to the display device and measure a latency or a packetdrop associated with transmitting the PPDUs. A display device mayattempt to transmit pose data frames or tracking frames and measure alatency or a packet drop associated with transmitting the frames. Therender device and the display device may perform other measurementsassociated with the XR experience, and the measurements may indicatewhen the XR experience is being impacted (such as measuring an increasein latency or packet drop). One or more parameters of the XR experiencemay be adjusted, and the measurements or the adjustments may beindicated to the other device.

Particular implementations can be implemented to realize one or more ofthe following potential advantages. Generating and providing feedbackmay allow the render device and the display device to determine when toadjust the XR experience to meet latency requirements or otherrequirements.

Some implementations more specifically relate to support of concurrentwireless links by one or more wireless communication devices. Inaccordance with some aspects of the present disclosure, a render orrelay device include concurrent links to an AP or STA and to a displaydevice. The render device or a relay device is to support the concurrentlinks while giving preference to communications with the display device(which may be associated with an XR experience having latency and otherrequirements). The render or relay device may use an enhanced set ofmulti-link operation (MLO) techniques or TWT mode techniques to supportthe concurrent links and meet the latency and other requirements of theXR experience. If a relay device supports concurrent links with an APand a display device, rendering of video frames for an XR experience maybe performed at the AP or a cloud server behind the AP. The video framesmay be sent from the AP to the relay device using a first link and sentfrom the relay device to the display device using a second linkconcurrent with the first link.

Particular implementations can be implemented to realize one or more ofthe following potential advantages. Support of the concurrent links mayallow the render or relay device to continue communicating with an AP oranother STA while still supporting an XR experience. In this manner, therender or relay device and the display device may be included in a BSS,mesh network, or other environment in which devices communicate withmultiple other devices while still supporting the XR experience.

FIG. 1A shows a block diagram of an example wireless communicationnetwork 100. According to some aspects, the wireless communicationnetwork 100 can be an example of a wireless local area network (WLAN)such as a Wi-Fi network (and will hereinafter be referred to as WLAN100). For example, the WLAN 100 can be a network implementing at leastone of the IEEE 802.11 family of standards (such as that defined by theIEEE 802.11-2016 specification or amendments thereof including, but notlimited to, 802.11ah, 802.11ad, 802.11ay, 802.11ax, 802.11az, 802.11ba,and 802.11be). The WLAN 100 may include numerous wireless communicationdevices such as an access point (AP) 102 and multiple stations (STAs)104. While only one AP 102 is shown, the WLAN network 100 also caninclude multiple APs 102.

Each of the STAs 104 also may be referred to as a mobile station (MS), amobile device, a mobile handset, a wireless handset, an access terminal(AT), a user equipment (UE), a subscriber station (SS), or a subscriberunit, among other possibilities. The STAs 104 may represent variousdevices such as mobile phones, personal digital assistant (PDAs), otherhandheld devices, netbooks, notebook computers, tablet computers,laptops, display devices (for example, TVs, computer monitors,navigation systems, HMDs, among others), music or other audio or stereodevices, remote control devices (“remotes”), printers, kitchen or otherhousehold appliances, key fobs (for example, for passive keyless entryand start (PKES) systems), among other possibilities.

A single AP 102 and an associated set of STAs 104 may be referred to asa basic service set (BSS), which is managed by the respective AP 102.FIG. 1A additionally shows an example coverage area 106 of the AP 102,which may represent a basic service area (BSA) of the WLAN 100. The BSSmay be identified to users by a service set identifier (SSID), as wellas to other devices by a basic service set identifier (BSSID), which maybe a medium access control (MAC) address of the AP 102. The AP 102periodically broadcasts beacon frames (“beacons”) including the BSSID toenable any STAs 104 within wireless range of the AP 102 to “associate”or re-associate with the AP 102 to establish a respective communicationlink 108 (hereinafter also referred to as a “Wi-Fi link”), or tomaintain a communication link 108, with the AP 102. For example, thebeacons can include an identification of a primary channel used by therespective AP 102 as well as a timing synchronization function forestablishing or maintaining timing synchronization with the AP 102. TheAP 102 may provide access to external networks to various STAs 104 inthe WLAN via respective communication links 108.

To establish a communication link 108 with an AP 102, each of the STAs104 is configured to perform passive or active scanning operations(“scans”) on frequency channels in one or more frequency bands (forexample, the 2.4 GHz, 5.0 GHz, 6.0 GHz, or 60 GHz bands). To performpassive scanning, a STA 104 listens for beacons, which are transmittedby respective APs 102 at a periodic time interval referred to as thetarget beacon transmission time (TBTT) (measured in time units (TUs)where one TU may be equal to 1024 microseconds (μs)). To perform activescanning, a STA 104 generates and sequentially transmits probe requestson each channel to be scanned and listens for probe responses from APs102. Each STA 104 may be configured to identify or select an AP 102 withwhich to associate based on the scanning information obtained throughthe passive or active scans, and to perform authentication andassociation operations to establish a communication link 108 with theselected AP 102. The AP 102 assigns an association identifier (AID) tothe STA 104 at the culmination of the association operations, which theAP 102 uses to track the STA 104.

As a result of the increasing ubiquity of wireless networks, a STA 104may have the opportunity to select one of many BSSs within range of theSTA or to select among multiple APs 102 that together form an extendedservice set (ESS) including multiple connected BSSs. An extended networkstation associated with the WLAN 100 may be connected to a wired orwireless distribution system that may allow multiple APs 102 to beconnected in such an ESS. As such, a STA 104 can be covered by more thanone AP 102 and can associate with different APs 102 at different timesfor different transmissions. Additionally, after association with an AP102, a STA 104 also may be configured to periodically scan itssurroundings to find a more suitable AP 102 with which to associate. Forexample, a STA 104 that is moving relative to its associated AP 102 mayperform a “roaming” scan to find another AP 102 having more desirablenetwork characteristics such as a greater received signal strengthindicator (RSSI) or a reduced traffic load.

In some cases, STAs 104 may form networks without APs 102 or otherequipment other than the STAs 104 themselves. One example of such anetwork is an ad hoc network (or wireless ad hoc network). Ad hocnetworks may alternatively be referred to as mesh networks orpeer-to-peer (P2P) networks. In some cases, ad hoc networks may beimplemented within a larger wireless network such as the WLAN 100. Insuch implementations, while the STAs 104 may be capable of communicatingwith each other through the AP 102 using communication links 108, STAs104 also can communicate directly with each other via direct wirelesslinks 110. Additionally, two STAs 104 may communicate via a directcommunication link 110 regardless of whether both STAs 104 areassociated with and served by the same AP 102. In such an ad hoc system,one or more of the STAs 104 may assume the role filled by the AP 102 ina BSS. Such a STA 104 may be referred to as a group owner (GO) and maycoordinate transmissions within the ad hoc network. Examples of directwireless links 110 include Wi-Fi Direct connections, connectionsestablished by using a Wi-Fi Tunneled Direct Link Setup (TDLS) link, andother P2P group connections.

The APs 102 and STAs 104 may function and communicate (via therespective communication links 108) according to the IEEE 802.11 familyof standards (such as that defined by the IEEE 802.11-2016 specificationor amendments thereof including, but not limited to, 802.11ah, 802.11ad,802.11ay, 802.11ax, 802.11az, 802.11ba, and 802.11be). These standardsdefine the WLAN radio and baseband protocols for the PHY and mediumaccess control (MAC) layers. The APs 102 and STAs 104 transmit andreceive wireless communications (hereinafter also referred to as “Wi-Ficommunications”) to and from one another in the form of physical layerconvergence protocol (PLCP) protocol data units (PPDUs). The APs 102 andSTAs 104 in the WLAN 100 may transmit PPDUs over an unlicensed spectrum,which may be a portion of spectrum that includes frequency bandstraditionally used by Wi-Fi technology, such as the 2.4 GHz band, the5.0 GHz band, the 60 GHz band, the 3.6 GHz band, and the 900 MHz band.Some implementations of the APs 102 and STAs 104 described herein alsomay communicate in other frequency bands, such as the 6.0 GHz band,which may support both licensed and unlicensed communications. The APs102 and STAs 104 also can be configured to communicate over otherfrequency bands such as shared licensed frequency bands, where multipleoperators may have a license to operate in the same or overlappingfrequency band or bands.

Each of the frequency bands may include multiple sub-bands or frequencychannels. For example, PPDUs conforming to the IEEE 802.11n, 802.11ac,and 802.11ax standard amendments may be transmitted over the 2.4 and 5.0GHz bands, each of which is divided into multiple 20 MHz channels. Assuch, these PPDUs are transmitted over a physical channel having aminimum bandwidth of 20 MHz, but larger channels can be formed throughchannel bonding. For example, PPDUs may be transmitted over physicalchannels having bandwidths of 40 MHz, 80 MHz, 160, or 320 MHz by bondingtogether multiple 20 MHz channels.

Each PPDU is a composite structure that includes a PHY preamble and apayload in the form of a PLCP service data unit (PSDU). The informationprovided in the preamble may be used by a receiving device to decode thesubsequent data in the PSDU. In instances in which PPDUs are transmittedover a bonded channel, the preamble fields may be duplicated andtransmitted in each of the multiple component channels. The PHY preamblemay include both a legacy portion (or “legacy preamble”) and anon-legacy portion (or “non-legacy preamble”). The legacy preamble maybe used for packet detection, automatic gain control and channelestimation, among other uses. The legacy preamble also may generally beused to maintain compatibility with legacy devices. The format of,coding of, and information provided in the non-legacy portion of thepreamble is based on the particular IEEE 802.11 protocol to be used totransmit the payload. A PPDU also may be referred to as a physical layerprotocol data unit or a PHY protocol data unit.

As noted above, devices (such as STAs 104) may communicate directly withone another. For an XR experience, a render device may communicatedirectly with a display device. For example, video frame data, audiodata, and sensor information may be communicated between the devicesproviding the XR experience to allow rendering and displaying video (orproviding audio or other data) synchronized with movements of thedisplay device.

As used herein, an XR experience refers to one or more of a virtualreality (VR, in which a user may be isolated from the real world),augmented reality (AR, in which a virtual world or virtual informationmay be overlaid on real world objects in a display), or mixed reality(MR, in which virtual objects and real world objects may be integratedinto a display that may appear seamless to the user) experience that maybe provided to a user. For example, the user may have a HMD (or otherdisplay device), audio device, or a haptic feedback device (such ashaptic gloves or vest) that is synchronized to provide information tothe user based on the user's movements.

FIG. 1B shows a pictorial diagram of a group 150 of example devices toprovide an XR experience. The device 152 is a display device to displayvideo frames of the XR experience. While the device 152 is depicted asan HMD, the device 152 may be any suitable display device, such as atablet or smartphone or eyeglasses. The device 154 is a device toprovide the video frames to the display device 152 over wirelesscommunication link 156. The device 154 may be an example implementationof a STA 104 in FIG. 1A. The device 154 may be configured as a softwareenabled AP (soft AP or SAP) for the display device 152. In someimplementations, the device 154 is a render device configured to renderthe video frames. In some implementations, the device 154 is a bridgedevice to obtain video frames rendered by a cloud server behind an AP158 or the AP 158 itself over a wireless communication link 160 andprovide the video frames to the device 152. While the device 154 isdepicted as a smartphone, the device 154 may be any suitable device forrendering or providing frames, such as a desktop computer, laptopcomputer, or tablet. While the device 154 is depicted as communicatingwith the AP 158, in some implementations, the device 154 communicateswith another STA in a peer-to-peer (P2P) mode. In the provided examples,an AP may refer to a STA communicably coupled to the device 154 in theP2P mode.

In some implementations, the device 152 or the device 154 is withinwireless communication range (also referred to as within range) of oneor more other devices. For example, one or more of the devices 152 or154 may be within range of device 162. The device 162 may be in the BSSof the AP 158 or may be in an other BSS (OBSS) associated with adifferent AP. The device 162 is configured to communicate on the samewireless medium as the device 154 (such as in the same frequency band,on the same channel, or on an overlapping channel). In this manner, thedevices 154 and 162 share the wireless medium to communicate with otherdevices.

Many of the examples below describe devices generating, providing, orobtaining PPDUs associated with video frames and video slices of videoframes. Aspects of the disclosure also apply to other types of dataprovided. For example, an application file may be a smallest segment ofdata that is recognizable by a receiving device at an application layer.A receiving device is unable to process any portion of the applicationfile at an application layer unless all portions of the application fileare obtained and joined to generate the entire application file. Anexample application file includes a video slice of a video frame. Asused herein, a video slice also may be referred to as a video frameslice or a slice. In processing video, each frame may be divided into aplurality of slices (such as a group of pixel columns, pixel rows,macroblocks, or other portions of a video frame), and each video slicemay be packaged into one or more PPDUs. While the below examples may bewith reference to an application file referring to a video slice, anapplication file may refer to other portions (such as a video frame) ormay include other data (such as audio, haptic information, a document,application scripts, and so on). In this manner, the device 152 may beother than a display device (such as an audio device or haptic feedbackdevice). As such, the present disclosure is not limited to themanagement and transport of video data and devices specific to such.

As noted above, many devices (including devices 152 and 154) may provideand obtain PPDUs between one another. For example, the AP 158 mayprovide and obtain PPDUs to and from the device 154. In another example,the device 154 may provide PPDUs to the device 152. FIGS. 2A-4 depictvarious example PPDUs. While the figures are described as PPDUscommunicated between the AP 102 and one or more STAs 104, the PPDUs maybe communicated between the device 154 and the device 152 (with thedevice 154 as a SAP and the device 152 as a STA of the SAP).

FIG. 2A shows an example protocol data unit (PDU) 200 usable forcommunications between wireless communication devices. For example, thePDU 200 can be configured as a PPDU. As shown, the PDU 200 includes aPHY preamble 202 and a PHY payload 204. For example, the PHY preamble202 may include a legacy portion that itself includes a legacy shorttraining field (L-STF) 206, a legacy long training field (L-LTF) 208,and a legacy signaling field (L-SIG) 210. The PHY preamble 202 also mayinclude a non-legacy portion (non-legacy fields 212). The L-STF 206generally enables a receiving device to perform automatic gain control(AGC) and coarse timing and frequency estimation. The L-LTF 208generally enables a receiving device to perform fine timing andfrequency estimation and also to estimate the wireless channel. TheL-SIG 210 generally enables a receiving device to determine a durationof the PDU and use the determined duration to avoid transmitting on topof the PDU. For example, the L-STF 206, the L-LTF 208, and the L-SIG 210may be modulated according to a binary phase shift keying (BPSK)modulation scheme. The payload 204 includes data 214. The payload 204may be modulated according to a BPSK modulation scheme, a quadratureBPSK (Q-BPSK) modulation scheme, a quadrature amplitude modulation (QAM)modulation scheme, or another appropriate modulation scheme. The payload204 may generally carry higher layer data, for example, in the form ofmedium access control (MAC) protocol data units (MPDUs) or aggregatedMPDUs (A-MPDUs).

FIG. 2B shows an example L-SIG field 220 in the PDU of FIG. 2A.

The L-SIG 220 includes a data rate field 222, a reserved bit 224, alength field 226, a parity bit 228, and a tail field 220. The data ratefield 222 indicates a data rate (note that the data rate indicated inthe data rate field 222 may not be the actual data rate of the datacarried in the payload 204). The length field 226 indicates a length ofthe packet in units of, for example, bytes. The parity bit 228 is usedto detect bit errors. The tail field 230 includes tail bits that areused by the receiving device to terminate operation of a decoder (forexample, a Viterbi decoder). The receiving device utilizes the data rateand the length indicated in the data rate field 222 and the length field226 to determine a duration of the packet in units of, for example,microseconds (μs).

FIG. 3A shows another example PDU 300 usable for wireless communicationbetween wireless communication devices. The PDU 300 may be used for SU,OFDMA or MU-MIMO transmissions. The PDU 300 may be formatted as a HighEfficiency (HE) WLAN PPDU in accordance with the IEEE 802.11ax amendmentto the IEEE 802.11 wireless communicate on protocol standard. The PDU300 includes a PHY preamble including a legacy portion 302 and anon-legacy portion 304. The PDU 300 may further include a PHY payload306 after the preamble, for example, in the form of a PSDU including adata field 324.

The legacy portion 302 of the preamble includes an L-STF 308, an L-LTF310, and an L-SIG 312. The non-legacy portion 304 includes a repetitionof L-SIG (RL-SIG) 314, a first HE signal field (HE-SIG-A) 316, an HEshort training field (HE-STF) 320, and one or more HE long trainingfields (or symbols) (HE-LTFs) 322. For OFDMA or MU-MIMO communications,the second portion 304 further includes a second HE signal field(HE-SIG-B) 318 encoded separately from HE-SIG-A 316. Like the L-STF 308,L-LTF 310, and L-SIG 312, the information in RL-SIG 314 and HE-SIG-A 316may be duplicated and transmitted in each of the component 20 MHzchannels in instances involving the use of a bonded channel. Incontrast, the content in HE-SIG-B 318 may be unique to each 20 MHzchannel and target specific STAs 104.

RL-SIG 314 may indicate to HE-compatible STAs 104 that the PDU 300 is anHE PPDU. An AP 102 may use HE-SIG-A 316 to identify and inform multipleSTAs 104 that the AP has scheduled UL or DL resources for them. Forexample, HE-SIG-A 316 may include a resource allocation subfield thatindicates resource allocations for the identified STAs 104. HE-SIG-A 316may be decoded by each HE-compatible STA 104 served by the AP 102. ForMU transmissions, HE-SIG-A 316 further includes information usable byeach identified STA 104 to decode an associated HE-SIG-B 318. Forexample, HE-SIG-A 316 may indicate the frame format, including locationsand lengths of HE-SIG-Bs 318, available channel bandwidths andmodulation and coding schemes (MCSs), among other examples. HE-SIG-A 316also may include HE WLAN signaling information usable by STAs 104 otherthan the identified STAs 104.

HE-SIG-B 318 may carry STA-specific scheduling information such as, forexample, STA-specific (or “user-specific”) MCS values and STA-specificRU allocation information. In the context of DL MU-OFDMA, suchinformation enables the respective STAs 104 to identify and decodecorresponding resource units (RUs) in the associated data field 324.Each HE-SIG-B 318 includes a common field and at least one STA-specificfield. The common field can indicate RU allocations to multiple STAs 104including RU assignments in the frequency domain, indicate which RUs areallocated for MU-MIMO transmissions and which RUs correspond to MU-OFDMAtransmissions, and the number of users in allocations, among otherexamples. The common field may be encoded with common bits, CRC bits,and tail bits. The user-specific fields are assigned to particular STAs104 and may be used to schedule specific RUs and to indicate thescheduling to other WLAN devices. Each user-specific field may includemultiple user block fields. Each user block field may include two userfields that contain information for two respective STAs to decode theirrespective RU payloads in data field 324.

FIG. 3B shows another example PPDU 350 usable for wireless communicationbetween wireless communication devices. The PDU 350 may be used for SU,OFDMA or MU-MIMO transmissions. The PDU 350 may be formatted as anExtreme High Throughput (EHT) WLAN PPDU in accordance with the IEEE802.11be amendment to the IEEE 802.11 wireless communication protocolstandard, or may be formatted as a PPDU conforming to any later(post-EHT) version of a new wireless communication protocol conformingto a future IEEE 802.11 wireless communication protocol standard orother wireless communication standard. The PDU 350 includes a PHYpreamble including a legacy portion 352 and a non-legacy portion 354.The PDU 350 may further include a PHY payload 356 after the preamble,for example, in the form of a PSDU including a data field 374.

The legacy portion 352 of the preamble includes an L-STF 358, an L-LTF360, and an L-SIG 362. The non-legacy portion 354 of the preambleincludes an RL-SIG 364 and multiple wireless communication protocolversion-dependent signal fields after RL-SIG 364. For example, thenon-legacy portion 354 may include a universal signal field 366(referred to herein as “U-SIG 366”) and an EHT signal field 368(referred to herein as “EHT-SIG 368”). One or both of U-SIG 366 andEHT-SIG 368 may be structured as, and carry version-dependentinformation for, other wireless communication protocol versions beyondEHT. The non-legacy portion 354 further includes an additional shorttraining field 370 (referred to herein as “EHT-STF 370,” although it maybe structured as, and carry version-dependent information for, otherwireless communication protocol versions beyond EHT) and one or moreadditional long training fields 372 (referred to herein as “EHT-LTFs372,” although they may be structured as, and carry version-dependentinformation for, other wireless communication protocol versions beyondEHT). Like L-STF 358, L-LTF 360, and L-SIG 362, the information in U-SIG366 and EHT-SIG 368 may be duplicated and transmitted in each of thecomponent 20 MHz channels in instances involving the use of a bondedchannel. In some implementations, EHT-SIG 368 may additionally oralternatively carry information in one or more non-primary 20 MHzchannels that is different than the information carried in the primary20 MHz channel.

EHT-SIG 368 may include one or more jointly encoded symbols and may beencoded in a different block from the block in which U-SIG 366 isencoded. EHT-SIG 368 may be used by an AP to identify and informmultiple STAs 104 that the AP has scheduled UL or DL resources for them.EHT-SIG 368 may be decoded by each compatible STA 104 served by the AP102. EHT-SIG 368 may generally be used by a receiving device tointerpret bits in the data field 376. For example, EHT-SIG 368 mayinclude RU allocation information, spatial stream configurationinformation, and per-user signaling information such as MCSs, amongother examples. EHT-SIG 368 may further include a cyclic redundancycheck (CRC) (for example, four bits) and a tail (for example, 6 bits)that may be used for binary convolutional code (BCC). In someimplementations, EHT-SIG 368 may include one or more code blocks thateach include a CRC and a tail. In some aspects, each of the code blocksmay be encoded separately.

EHT-SIG 368 may carry STA-specific scheduling information such as, forexample, user-specific MCS values and user-specific RU allocationinformation. EHT-SIG 368 may generally be used by a receiving device tointerpret bits in the data field 376. In the context of DL MU-OFDMA,such information enables the respective STAs 104 to identify and decodecorresponding RUs in the associated data field 376. Each EHT-SIG 368 mayinclude a common field and at least one user-specific field. The commonfield can indicate RU distributions to multiple STAs 104, indicate theRU assignments in the frequency domain, indicate which RUs are allocatedfor MU-MIMO transmissions and which RUs correspond to MU-OFDMAtransmissions, and the number of users in allocations, among otherexamples. The common field may be encoded with common bits, CRC bits,and tail bits. The user-specific fields are assigned to particular STAs104 and may be used to schedule specific RUs and to indicate thescheduling to other WLAN devices. Each user-specific field may includemultiple user block fields. Each user block field may include, forexample, two user fields that contain information for two respectiveSTAs to decode their respective RU payloads.

The presence of RL-SIG 364 and U-SIG 366 may indicate to EHT- or laterversion-compliant STAs 104 that the PPDU 350 is an EHT PPDU or a PPDUconforming to any later (post-EHT) version of a new wirelesscommunication protocol conforming to a future IEEE 802.11 wirelesscommunication protocol standard. For example, U-SIG 366 may be used by areceiving device to interpret bits in one or more of EHT-SIG 368 or thedata field 376.

FIG. 4 shows an example PPDU 400 usable for communications between an AP102 and a number of STAs 104. As described above, each PPDU 400 includesa PHY preamble 402 and a PSDU 404. Each PSDU 404 may carry one or moreMAC protocol data units (MPDUs). For example, each PSDU 404 may carry anaggregated MPDU (A-MPDU) 408 that includes an aggregation of multipleA-MPDU subframes 406. Each A-MPDU subframe 406 may include a MACdelimiter 410 and a MAC header 412 prior to the accompanying MPDU 414,which includes the data portion (“payload” or “frame body”) of theA-MPDU subframe 406. The MPDU 414 may carry one or more MAC service dataunit (MSDU) subframes 416. For example, the MPDU 414 may carry anaggregated MSDU (A-MSDU) 418 including multiple MSDU subframes 416. EachMSDU subframe 416 contains a corresponding MSDU 420 preceded by asubframe header 422.

Referring back to the A-MPDU subframe 406, the MAC header 412 mayinclude a number of fields containing information that defines orindicates characteristics or attributes of data encapsulated within theframe body 414. The MAC header 412 also includes a number of fieldsindicating addresses for the data encapsulated within the frame body414. For example, the MAC header 412 may include a combination of asource address, a transmitter address, a receiver address, or adestination address. The MAC header 412 may include a frame controlfield containing control information. The frame control field specifiesthe frame type, for example, a data frame, a control frame, or amanagement frame. The MAC header 412 may further include a durationfield indicating a duration extending from the end of the PPDU until theend of an acknowledgment (ACK) of the last PPDU to be transmitted by thewireless communication device (for example, a block ACK (BA) in the caseof an A-MPDU). The use of the duration field serves to reserve thewireless medium for the indicated duration, thus establishing the NAV.Each A-MPDU subframe 406 also may include a frame check sequence (FCS)field 424 for error detection. For example, the FCS field 424 mayinclude a cyclic redundancy check (CRC).

As described above, APs 102 and STAs 104 can support multi-user (MU)communications; that is, concurrent transmissions from one device toeach of multiple devices (for example, multiple simultaneous downlink(DL) communications from an AP 102 to corresponding STAs 104), orconcurrent transmissions from multiple devices to a single device (forexample, multiple simultaneous uplink (UL) transmissions fromcorresponding STAs 104 to an AP 102). To support the MU transmissions,the APs 102 and STAs 104 may utilize multi-user multiple-input,multiple-output (MU-MIMO) and multi-user orthogonal frequency divisionmultiple access (MU-OFDMA) techniques.

In MU-OFDMA schemes, the available frequency spectrum of the wirelesschannel may be divided into multiple resource units (RUs) each includinga number of different frequency subcarriers (“tones”). Different RUs maybe allocated or assigned by an AP 102 to different STAs 104 atparticular times. The sizes and distributions of the RUs may be referredto as an RU allocation. In some implementations, RUs may be allocated in2 MHz intervals, and as such, the smallest RU may include 26 tonesconsisting of 24 data tones and 2 pilot tones. Consequently, in a 20 MHzchannel, up to 9 RUs (such as 2 MHz, 26-tone RUs) may be allocated(because some tones are reserved for other purposes). Similarly, in a160 MHz channel, up to 74 RUs may be allocated. Larger 52 tone, 106tone, 242 tone, 484 tone and 996 tone RUs also may be allocated.Adjacent RUs may be separated by a null subcarrier (such as a DCsubcarrier), for example, to reduce interference between adjacent RUs,to reduce receiver DC offset, and to avoid transmit center frequencyleakage.

For UL MU transmissions, an AP 102 can transmit a trigger frame toinitiate and synchronize an UL MU-OFDMA or UL MU-MIMO transmission frommultiple STAs 104 to the AP 102. Such trigger frames may thus enablemultiple STAs 104 to send UL traffic to the AP 102 concurrently in time.A trigger frame may address one or more STAs 104 through respectiveassociation identifiers (AIDs), and may assign each AID (and thus eachSTA 104) one or more RUs that can be used to send UL traffic to the AP102. The AP also may designate one or more random access (RA) RUs forwhich unscheduled STAs 104 may contend.

FIG. 5 shows a block diagram of an example wireless communication device500. In some implementations, the wireless communication device 500 canbe an example of a device for use in a STA such as one of the STAs 104described above with reference to FIG. 1A or one or both of the devices152 or 154 with reference to FIG. 1B. In some implementations, thewireless communication device 500 can be an example of a device for usein an AP such as the AP 102 described above with reference to FIG. 1A.The wireless communication device 500 is capable of transmitting (oroutputting for transmission) and receiving wireless communications (forexample, in the form of wireless packets). For example, the wirelesscommunication device can be configured to transmit and receive packetsin the form of PPDUs and MPDUs conforming to an IEEE 802.11 standard,such as that defined by the IEEE 802.11-2016 specification or amendmentsthereof including, but not limited to, 802.11ah, 802.1 lad, 802.11ay,802.11ax, 802.11az, 802.11ba, and 802.11be.

The wireless communication device 500 can be, or can include, a chip,system on chip (SoC), chipset, package, or device that includes one ormore modems 502, for example, a Wi-Fi (IEEE 802.11 compliant) modem. Insome implementations, the one or more modems 502 (collectively “themodem 502”) additionally include a WWAN modem (for example, a 3GPP 4GLTE or 5G compliant modem). In some implementations, the wirelesscommunication device 500 also includes one or more radios 504(collectively “the radio 504”). In some implementations, the wirelesscommunication device 506 further includes one or more processors,processing blocks or processing elements 506 (collectively “theprocessor 506”), and one or more memory blocks or elements 508(collectively “the memory 508”).

The modem 502 can include an intelligent hardware block or device suchas, for example, an application-specific integrated circuit (ASIC) amongother possibilities. The modem 502 is generally configured to implementa PHY layer. For example, the modem 502 is configured to modulatepackets and to output the modulated packets to the radio 504 fortransmission over the wireless medium. The modem 502 is similarlyconfigured to obtain modulated packets received by the radio 504 and todemodulate the packets to provide demodulated packets. In addition to amodulator and a demodulator, the modem 502 may further include digitalsignal processing (DSP) circuitry, automatic gain control (AGC), acoder, a decoder, a multiplexer, and a demultiplexer. For example, whilein a transmission mode, data obtained from the processor 506 is providedto a coder, which encodes the data to provide encoded bits. The encodedbits are mapped to points in a modulation constellation (using aselected MCS) to provide modulated symbols. The modulated symbols may bemapped to a number N_(SS) of spatial streams or a number N_(STS) ofspace-time streams. The modulated symbols in the respective spatial orspace-time streams may be multiplexed, transformed via an inverse fastFourier transform (IFFT) block, and subsequently provided to the DSPcircuitry for Tx windowing and filtering. The digital signals may beprovided to a digital-to-analog converter (DAC). The resultant analogsignals may be provided to a frequency upconverter, and ultimately, theradio 504. In implementations involving beamforming, the modulatedsymbols in the respective spatial streams are precoded via a steeringmatrix prior to their provision to the IFFT block.

While in a reception mode, digital signals received from the radio 504are provided to the DSP circuitry, which is configured to acquire areceived signal, for example, by detecting the presence of the signaland estimating the initial timing and frequency offsets. The DSPcircuitry is further configured to digitally condition the digitalsignals, for example, using channel (narrowband) filtering, analogimpairment conditioning (such as correcting for I/Q imbalance), andapplying digital gain to ultimately obtain a narrowband signal. Theoutput of the DSP circuitry may be fed to the AGC, which is configuredto use information extracted from the digital signals, for example, inone or more received training fields, to determine an appropriate gain.The output of the DSP circuitry also is coupled with the demodulator,which is configured to extract modulated symbols from the signal and,for example, compute the logarithm likelihood ratios (LLRs) for each bitposition of each subcarrier in each spatial stream. The demodulator iscoupled with the decoder, which may be configured to process the LLRs toprovide decoded bits. The decoded bits from all of the spatial streamsare fed to the demultiplexer for demultiplexing. The demultiplexed bitsmay be descrambled and provided to the MAC layer (the processor 506) forprocessing, evaluation, or interpretation.

The radio 504 generally includes at least one radio frequency (RF)transmitter (or “transmitter chain”) and at least one RF receiver (or“receiver chain”), which may be combined into one or more transceivers.For example, the RF transmitters and receivers may include various DSPcircuitry including at least one power amplifier (PA) and at least onelow-noise amplifier (LNA), respectively. The RF transmitters andreceivers may in turn be coupled to one or more antennas. For example,in some implementations, the wireless communication device 500 caninclude, or be coupled with, multiple transmit antennas (each with acorresponding transmit chain) and multiple receive antennas (each with acorresponding receive chain). The symbols output from the modem 502 areprovided to the radio 504, which transmits the symbols via the coupledantennas. Similarly, symbols received via the antennas are obtained bythe radio 504, which provides the symbols to the modem 502.

The processor 506 can include an intelligent hardware block or devicesuch as, for example, a processing core, a processing block, a centralprocessing unit (CPU), a microprocessor, a microcontroller, a digitalsignal processor (DSP), an application-specific integrated circuit(ASIC), a programmable logic device (PLD) such as a field programmablegate array (FPGA), discrete gate or transistor logic, discrete hardwarecomponents, or any combination thereof designed to perform the functionsdescribed herein. The processor 506 processes information receivedthrough the radio 504 and the modem 502, and processes information to beoutput through the modem 502 and the radio 504 for transmission throughthe wireless medium. For example, the processor 506 may implement acontrol plane and MAC layer configured to perform various operationsrelated to the generation and transmission of MPDUs, frames, or packets.The MAC layer is configured to perform or facilitate the coding anddecoding of frames, spatial multiplexing, space-time block coding(STBC), beamforming, and OFDMA resource allocation, among otheroperations or techniques. In some implementations, the processor 506 maygenerally control the modem 502 to cause the modem to perform variousoperations described above.

The memory 504 can include tangible storage media such as random-accessmemory (RAM) or read-only memory (ROM), or combinations thereof. Thememory 504 also can store non-transitory processor- orcomputer-executable software (SW) code containing instructions that,when executed by the processor 506, cause the processor to performvarious operations described herein for wireless communication,including the generation, transmission, reception, and interpretation ofMPDUs, frames or packets. For example, various functions of componentsdisclosed herein, or various blocks or steps of a method, operation,process, or algorithm disclosed herein, can be implemented as one ormore modules of one or more computer programs.

FIG. 6A shows a block diagram of an example AP 602. For example, the AP602 can be an example implementation of the AP 102 described withreference to FIG. 1A or the AP 158 described with reference to FIG. 1B.The AP 602 includes a wireless communication device (WCD) 610. Forexample, the wireless communication device 610 may be an exampleimplementation of the wireless communication device 500 described withreference to FIG. 5 . The AP 602 also includes multiple antennas 620coupled with the wireless communication device 610 to transmit andreceive wireless communications. In some implementations, the AP 602additionally includes an application processor 630 coupled with thewireless communication device 610, and a memory 640 coupled with theapplication processor 630. The AP 602 further includes at least oneexternal network interface 650 that enables the AP 602 to communicatewith a core network or backhaul network to gain access to externalnetworks including the Internet. For example, the external networkinterface 650 may include one or both of a wired (for example, Ethernet)network interface and a wireless network interface (such as a WWANinterface). Ones of the aforementioned components can communicate withother ones of the components directly or indirectly, over at least onebus. The AP 602 further includes a housing that encompasses the wirelesscommunication device 610, the application processor 630, the memory 640,and at least portions of the antennas 620 and external network interface650.

FIG. 6B shows a block diagram of an example STA 604. For example, theSTA 604 can be an example implementation of the STA 104 described withreference to FIG. 1A or one or more of the devices 152 or 154 describedwith reference to FIG. 1B. The STA 604 includes a wireless communicationdevice 615. For example, the wireless communication device 615 may be anexample implementation of the wireless communication device 500described with reference to FIG. 5 . The STA 604 also includes one ormore antennas 624 coupled with the wireless communication device 615 totransmit and receive wireless communications. The STA 604 additionallyincludes an application processor 635 coupled with the wirelesscommunication device 615, and a memory 645 coupled with the applicationprocessor 635. In some implementations, the STA 604 further includes auser interface (UI) 655 (such as a touchscreen or keypad) and a display665, which may be integrated with the UI 655 to form a touchscreendisplay. In some implementations, the STA 604 may further include one ormore sensors 675 such as, for example, one or more inertial sensors,accelerometers, temperature sensors, pressure sensors, or altitudesensors. Ones of the aforementioned components can communicate withother ones of the components directly or indirectly, over at least onebus. The STA 604 further includes a housing that encompasses thewireless communication device 615, the application processor 635, thememory 645, and at least portions of the antennas 624, UI 655, anddisplay 665.

In some implementations of a device 152, the STA 604 may be, mayinclude, or may be coupled to a HMD or other device used to provide anXR experience to a user (such as an audio device (including headphones),haptic gloves, a haptic vest, and so on). If the STA 604 includes a HMD,the display 665 may be integrated into glasses, a monocle, or other headmounted unit. In this manner, the STA 604 may be a display device for anXR experience. The sensors 675 may include an inertial measurement unit(IMU), which may include a gyroscope, an accelerometer, or other sensorsto determine an orientation or motion of the STA 604. For example, theIMU may be included in an HMD to measure the orientation or motion ofthe HMD as a user moves his or her head. The orientation information(and, optionally, the motion information) of the device may be referredto as pose information. The IMU measures the pose information at adefined interval (such as every 100 microseconds (μs)).

In some implementations, the display device (such as a HMD) includes oneor more cameras in its sensors 675. The one or more cameras may be usedby the display device to generate tracking frames or other trackinginformation to be used by the render device in generating video frames.The tracking information may include markers or points in the user'sfield of view (FOV) in the HMD used to determine locations ofinformation or objects in the video frames. For example, markersindicating a location of a building door may be used to render a videoframe to overlay a name of a business, open hours, and so on near thedoor in the user's FOV. In this manner, the UL traffic from the displaydevice to the render device may include pose data frames (also referredto as pose frames) and tracking frames. While rendering is described inthe examples as being based on a pose frame, rendering also may be basedon one or more tracking frames from the display device.

In some implementations of a device 154, the STA 604 may be configuredas a SAP to the device 152. The software to cause the STA 604 to act asa SAP may be stored in memory 645 (or another suitable memory of the STA604) and executed by the application processor 635. In this manner, theSTA 604 (acting as a SAP) may perform some functionalities of the AP602.

The render device for an XR experience may be the device 154 (which maybe a STA 604 acting as a SAP), the AP 158 (with the device 154 acting asa bridge device), or a combination of both. The AP 602 may be referredto in the examples herein in describing a render device for an XRexperience only for clarity and simplicity in explaining aspects of thepresent disclosure. The display device for an XR experience is thedevice 152. The STA 604 may be referred to in the examples herein indescribing a display device for an XR experience. In someimplementations, the render device and the display device maycommunicate over a 6 GHz frequency band (such as to transmit PPDUs orpose packets between the devices). However, any suitable frequency bandmay be used (such as 5 GHz or other frequency bands defined in the IEEE802.11 standard). The downlink (DL) transmission rate from the renderdevice to the display device may be at least 50 megabits per second(Mbps) to 120 Mbps to support 45 to 60 frames per second (fps), and theuplink (UL) transmission rate from the display device to the renderdevice may be a minimum of 0.5 Mbps to 20 Mbps. The devices may beconfigured such that one way latency (such as on the DL or on the UL) isless than 10 ms.

The application processor 630 or 635 may be configured to execute one ormore host layers of the open systems interconnection (OSI) model,including the application layer. As used herein, the application layerof the render device may refer to the application processor 630 or othercomponents performing operations at the application layer. Theapplication layer for an XR experience at the render device may includerendering for an XR application executed by the render device. As usedherein, the application layer of the display device may refer to theapplication processor 635 or other components performing operations atthe application layer. The application layer for an XR experience at thedisplay device may include displaying a video for an XR applicationexecuted by the display device.

The WCD 610 or 615 may be configured to execute one or more layers ofthe OSI model, such as the network layer, the media access control layer(MAC), or the physical layer (PHY). One or more of the layers may bereferred to as a wireless layer or a Wi-Fi layer. As used herein, thewireless layer of the render device may refer to the WCD 610 performingoperations at the wireless layer. As used herein, the wireless layer ofthe display device may refer to the WCD 615 performing operations at thewireless layer.

The process from measuring pose information to render a video framebased on the pose information may be referred to as motion-to-render(M2R). The process from rendering the video frame to displaying thevideo frame may be referred to as render-to-photon (R2P). The overallprocess from measuring pose information to rendering a video frame usingthe pose information to displaying the video frame may be referred to asmotion-to-render-to-photon (M2R2P). In some implementations, the renderdevice and the display device are configured such that M2R2P is lessthan 70 ms (such as between 50 and 70 ms).

FIG. 7 shows a sequence diagram 700 illustrating example M2R2Poperations. The example M2R2P operations are with reference to one videoframe, and the M2R2P operations may be repeated for each video frame.The timings of operations are not drawn to scale, and some operationsmay be slightly later than previous operations or may take a longer orshorter amount of time than as depicted.

The IMU of the display device generates a plurality of IMU measurements(702). Each line indicates an IMU measurement. As depicted, the IMUmeasurements may be periodic without reference to when video frames areto be rendered or displayed. For a video frame to be rendered anddisplayed, the display device generates an IMU measurement packet (704)from one of the IMU measurements. The IMU measurement that is selectedmay be the current IMU measurement when a request for the packet isobtained from the render device or when the packet is to be generatedbased on a defined periodicity for the packets. After generating the IMUmeasurement packet, the display device may transmit the packet to therender device during an UL transmission 706 of a transmit/receive window708. The render device may render and encode the video frame (710) basedon the pose information (or other information) obtained in the IMUmeasurement packet. The render device may generate one or more PPDUs toinclude the encoded video frame data and transmit the one or more PPDUsto the display device during a DL transmission 712 of a transmit/receivewindow 708. The timing of the UL and DL transmissions 706 and 712include over the air (OTA) time and processing time at the wirelesslayer. The display device may decode the video frame (714). In someimplementations, the display device may use a jitter buffer (716) tocapture decoded frame information and smooth video frame generationtimes to prevent jitter in the video. For example, the jitter buffer isused to ensure a fixed playback schedule of video frames by removingvariations in decoding times. In some implementations, the displaydevice may perform asynchronous time warping (ATW) on one or more videoframes (718) to increase the perceived frame rate of the displayed videoor compensate for latency between when the IMU measurement occurs andwhen the video frame is displayed. The display device displays the videoframe (720), which is a video frame based on the selected IMUmeasurement at 702.

As used herein, an IMU measurement may be referred to as poseinformation, and an IMU measurement packet may be referred to as a posepacket or pose data packet. Pose information may include an orientationof the device with reference to the azimuth, a movement of the device, alocation of the device, or other characteristics of a particularposition of the device used to generate appropriate video frames to bedisplayed by the device. In FIG. 7 , the pose packet is depicted asbeing generated once for each video frame. In some implementations, thepose packet may be generated at a higher frequency than once for eachvideo frame. For example, a 60 fps video corresponds to 16.67 ms pervideo frame, and the display device may generate a pose packet every 2ms. In this manner, at least 8 pose packets may be generated duringdisplay of one video frame. The display device may select the mostrecent pose packet when a pose packet is to be provided to the renderdevice. The render device may generate a video frame based on theobtained pose packet. In some implementations, a most recent pose packetmay not be obtained by the render device because of a DL transmissionfrom the render device to the display device. The render device may usethe last obtained pose packet to generate a video frame. To reduce thelatency between the pose packet and rendering the video frame, thedisplay device may provide a plurality of pose packets during renderingand encoding a previous video frame. In some other implementations,sending of the pose packets is synchronized with rendering and encoding.In this manner, timing of sending the pose packet is ensured so that therender device obtains the pose packet to render a next video frame.

Regarding access to the wireless medium, M2R2P latency requirements ofan XR experience may cause the wireless system to provide preference tothe render device and the display device to obtain control of thewireless medium. Preference to the render device and the display devicemay be with reference to other devices in the same BSS or one or moredevices from OBSSs within range of the render device or the displaydevice. Obtaining control of the wireless medium may refer to a device(such as the render device) obtaining control of one or more wirelesschannels for transmission or reception. Access to one or more wirelesschannels may be asynchronous (in which devices contend for the wirelessmedium during contention windows) or synchronous (in which one or moreAPs coordinate access to the wireless medium between devices). Asdescribed in the examples below, providing preference may includeadjusting one or more contention parameters (such as a backoff timervalue or one or more EDCA parameters) or coordinatingtransmission/reception windows between the render device and the displaydevice to prevent interference by one or more other devices transmittingon the wireless medium. Asynchronous control of the wireless medium maybe referred to as asynchronous channel access control. Synchronouscontrol of the wireless medium may be referred to as synchronous channelaccess control. The wireless system also may be configured to preventcollisions between DL and UL traffic between the render device and thedisplay device, prevent interference between links between the renderdevice and an AP and the render device and the display device, or allowpower saving at the render device or the display device based on channelaccess control.

FIG. 8 shows a flowchart illustrating an example process 800 forasynchronous channel access control according to some implementations.Control of the wireless medium and other operations in the exampleprocess may be performed by a device (such as the device 154 in FIG. 1B)or a wireless communication device implemented in the device (such asthe WCD 615 in FIG. 6B). The device performing the operations may be arender device of an XR experience.

At 802, the device obtains control of a wireless medium. Control of thewireless medium is associated with a first priority of transmitting,over the wireless medium, a first PPDU of an application file from thedevice to a second device (804). The first priority is different than asecond priority of transmitting data from the second device to thedevice over the wireless medium (806). As noted above, an applicationfile may be a smallest portion of data that is whole (without missingportions) that can be processed by a device.

At 808, the device provides the first PPDU to the second device.

At 810, the device provides one or more subsequent PPDUs of theapplication file to the second device. In some implementations, thesecond device is a display device, and the application file isassociated with a video frame (such as including a video slice of avideo frame). In this manner, a plurality of PPDUs (including the firstPPDU and the one or more subsequent PPDUs) may be associated with avideo frame. The action of providing the one or more subsequent PPDUs isassociated with a third priority of transmitting the one or moresubsequent PPDUs over the wireless medium (812).

The first priority may be associated with a first set of EDCAparameters, the second priority may be associated with a second set ofEDCA parameters, and the third priority may be associated with a thirdset of EDCA parameters. EDCA parameters may include one or more of anarbitration interframe spacing number (AIFSN), a minimum contentionwindow (CWmin), or a maximum contention window (CWmax) used by therender device or the display device to determine when to transmit to theother device (such as based on CW mechanisms defined in the IEEE 802.11standards). For example, the first priority may be associated withaggressive EDCA parameters to obtain control of the wireless medium overall other devices to contend for the wireless medium. In a specificexample, the CWmin and the CWmax for the first priority are a firstlength that is less than other CWs used by the other devices. Inaddition or to the alternative, the AIFSN for the first priority is alower number than other AIFSNs used by the other devices. For example,lower numbers may indicate a priority of the traffic based on aclassification of the packets to be transmitted (such as high priority,best effort, and so on). A lower priority or a higher priority may referto a higher or lower AIFSN, respectively. The AIFSN may be 1 for thefirst priority to indicate highest priority traffic to be transmitted,and the AIFSN may be 3 for the third priority to indicate traffic with alower priority than the first priority. The AIFSN may be 2 for thesecond priority to indicate traffic with a higher priority than thethird priority and a lower priority than the first priority. In someimplementations, the render device may reserve the CW for both therender device and the display device. In this manner, the CWmin andCWmax may be set to 0 for the display device.

The first priority also may be associated with a first backoff countervalue for contention of the wireless medium, the second priority alsomay be associated with a second backoff counter value for contention ofthe wireless medium, and the third priority also may be associated witha third backoff counter value for contention of the wireless medium. Abackoff counter is set to the backoff counter value, and the backoffcounter counts down until 0 for a transmit opportunity (TXOP) on thewireless medium. When the backoff counter reaches 0, the device attemptsto transmit on the wireless medium (such as performing carrier sense todetermine if the wireless medium is unoccupied and transmitting on thewireless medium based on the carrier sense). A shorter backoff countervalue corresponds to a device attempting to transmit on the wirelessmedium sooner. In some implementations, the first backoff counter valueis less than the second backoff counter value, and the second backoffcounter value is less than the third backoff counter value. In thismanner, a first PPDU (such as for a video frame) from a render devicemay be attempted to be transmitted sooner than data (such as a posepacket) from the display device, and the data from the display devicemay be attempted to be transmitted sooner than the one or moresubsequent PPDUs (such as for the video frame) from the render device.In some implementations, the first backoff counter value may be 0, thesecond backoff counter value may indicate a time period greater than ashort interframe spacing (SIFS), and the third backoff counter value mayindicate a time period greater than indicated by the second backoffcounter value.

The render device provides the first PPDU associated with the firstpriority and the one or more subsequent PPDUs associated with the thirdpriority. The render device may configure itself to adjust the one ormore EDCA parameters from the first set of parameters to the third setof parameters after transmitting the first PPDU. The render device alsomay adjust the backoff counter value from the first value to the thirdvalue (such as by setting the backoff counter to the third value for thesubsequent PPDUs) after transmitting the first PPDU. Using differentsets of EDCA parameters and backoff counter values, the render devicehas a higher probability of transmitting the first PPDU relative toother devices (including the display device and other devices in OBSSs).Conversely, the display device may transmit data (such as pose packets)to the render device before the one or more subsequent PPDUs aretransmitted to the display device.

In some implementations, the render device uses a request to send(RTS)/clear to send (CTS) mechanism to obtain control of and reserve thewireless medium. For example, the render device may provide (such asbroadcast) a first RTS frame to obtain control of the wireless medium.The RTS frame may be transmitted based on the first backoff countervalue. The first RTS frame includes an indication of a networkallocation vector (NAV) to maintain control of the wireless medium for afirst time period. The NAV indicates the time period that the wirelessmedium is reserved by the device. In this manner, other devices withinrange of the render device receive the RTS frame, process the RTS frame,and set their NAV to the indicated amount of time to preventtransmitting on the wireless medium for the amount of time indicated.The example RTS/CTS mechanism and transmission of data between therender device and display device is described in more detail below withreference to FIG. 10 .

FIG. 8 depicts an example process from the render device perspective.FIG. 9 depicts the example process from the display device perspective.

FIG. 9 shows a flowchart illustrating an example process 900 forasynchronous channel access control according to some implementations.Operations in the example process may be performed by a device (such asthe device 152 in FIG. 1B) or a wireless communication deviceimplemented in the device (such as the WCD 615 in FIG. 6B). The deviceperforming the operations may be a display device of an XR experience.

At 902, the device obtains a first PPDU of an application file from asecond device over a wireless medium. For an XR experience, the devicemay be a display device, and the second device may be a render device.The second device may refer to an infrastructure AP, an SAP (such as thedevice 154 in FIG. 1B acting as an SAP) or another device to provide thePPDUs of the application file to the device (the second device may bereferred to as an AP or a render device in the below examples withreference to FIGS. 9 and 10 ). In some implementations, the applicationfile includes one or more video slices of a video frame.

The second device obtains control of the wireless medium to provide thefirst PPDU (904), and control of the wireless medium is associated witha first priority of transmitting the first PPDU over the wireless medium(906). The first priority is different than a second priority oftransmitting data from the device to the second device over the wirelessmedium (908).

At 910, the device obtains one or more subsequent PPDUs of theapplication file from the second device. The action of obtaining the oneor more subsequent PPDUs is associated with a third priority oftransmitting the one or more subsequent PPDUs over the wireless medium(912). As noted above, the priorities may be associated with one or moreof a backoff counter value or sets of EDCA parameters.

FIG. 10 shows a sequence diagram 1000 illustrating example transmissionsbetween devices for an XR experience. The devices are depicted as arender device and a display device for explanation purposes, but theconcepts described may be extended to other types of devices. Start timeto may indicate the beginning of a CW or other moment when the renderdevice is to begin its backoff (BO) counter (such as when one or morePPDUs are ready for transmission at the render device). The BO counterof the render device is set to the first backoff counter value (first BOvalue) associated with the first PPDU of an application file (such as ofa video frame). If the display device is to begin its BO counter, the BOcounter of the display device is set to the second backoff counter value(second BO value) associated with the data to be transmitted from thedisplay device to the render device.

After a BO time period based on the first BO value (time t₁), the renderdevice may send a RTS frame. The end of the RTS frame on the wirelessmedium is at time t₂. The display device sends a CTS frame to the renderdevice a SIFS duration after time t₂ (time t₃). Sending the CTS framemay be based on the display device obtaining the RTS frame (which mayindicate that the wireless medium is free) and that the display deviceis ready to obtain data from the render device. The end of the CTS frameon the wireless medium is at time t₄. The render device sends a firstPPDU of an application file (such as of a video frame) to the displaydevice a SIFS duration after time t₄ (time t₅).

While not depicted, if the CTS frame is not obtained by the renderdevice, the render device may again wait the BO time period and attemptto resend the RTS frame to the display device. In some implementations,the render device is configured to retry sending the RTS frame fivetimes before indicating that sending the RTS frame failed. In someimplementations, the RTS/CTS mechanism before reserving the wirelessmedium is associated with a video frame. If sending the RTS fails (andthe render device is unable to obtain control of the wireless medium),the render device may prevent providing the associated frame to thedisplay device and attempt to obtain control of the wireless medium toprovide the next frame to the display device. If a video frame isskipped, the display device may repeat the previously displayed videoframe or not display a video frame at the time the missed video frame isto be displayed. In some implementations, if a video frame is skipped,one or more parameters of the DL communications (such as a modulationand coding scheme (MCS), a frame rate, forward error correction (FEC),and so on) may be adjusted to attempt to reduce the bandwidthrequirements and attempt to increase the probability of delivering videoframes to the display device.

Referring back to FIG. 10 , the end of the first PPDU on the wirelessmedium is at time t₆. The display device sends a block acknowledgement(BA) to the render device a SIFS duration after time t₆ (time t₇). TheBA indicates that the display device obtained the first PPDU. The BAalso may indicate if any portions (such as one or more MPDUs) werecorrupted or missing (such as by indicating which MPDUs (which includeone or more MSDUs) were obtained in the first PPDU). If the renderdevice does not obtain a BA, the render device may attempt to resend thefirst PPDU to the display device.

The end of the BA on the wireless medium is at time t₈. The renderdevice sends a second PPDU to the display device a SIFS duration aftertime t₈ (time t₉), with the end of the second PPDU on the wirelessmedium at time t₁₀. The process may repeat for one or more PPDUs to betransmitted from the render device to the display device during theTXOP. For example, the render device may send an Nth PPDU at time t₁₁(for N greater than or equal to 1). The end of the Nth PPDU on thewireless medium is at time t12. The display device sends a BA to therender device a SIFS duration after time t12 (time t13), with the end ofthe BA on the wireless medium at time t₁₄.

Referring back to the RTS frame, the RTS frame indicates a NAV value toreserve the wireless medium for a duration of time greater than the TXOP(such as the original NAV protection duration indicated). For example, aTXOP may be configurable by the render device for up to a 2.5 msduration. The RTS frame indicates a NAV value an amount equal to orgreater than 2.5 ms in case the render device is to extend the NAVprotection. Setting the NAV may refer to the render device indicating avalue to set each receiving device's NAV to prevent the receiving devicefrom transmitting for the amount of time. Extending the NAV may refer tothe render device indicating a NAV padding value or new NAV value toincrease or set each receiving device's NAV to extend the amount of timethe receiving device is to prevent transmitting. The NAV duration andthe TXOP may begin at the start time of the RTS frame. In someimplementations, the render device indicates the NAV duration as set tothe TXOP duration (such as 2.5 ms). The render device also may indicatein each PPDU (such as the first PPDU up through the Nth PPDU) a minimumNAV value to ensure the remaining NAV is a minimum duration or to extendthe NAV (such as indicating a NAV padding of 1 ms following the PPDUtransmission).

The display device may run its BO counter (set to the second BO value)at the end of the TXOP (such as at time t₁₄). During the BO time, thedisplay device listens to the wireless medium for incoming traffic. Ifthe wireless medium remains clear by the time the BO counter reaches 0(such as at time t₁₅), the display device may send data to the renderdevice. The data from the display device may include pose information orany other suitable UL data for the XR experience.

The end of the data on the wireless medium is at time t₁₆. The renderdevice sends a BA to the display device a SIFS duration after time t₁₆(time t₁₇), with the end of the BA on the wireless medium at time tis.The render device may have one or more subsequent PPDUs of theapplication file to send to the display device. For example, sending avideo frame may not be completed during a first TXOP, and the remainderof the video frame is to be sent during one or more subsequent TXOPs. Asdepicted, the original NAV protection indicates that the wireless mediumis still reserved by the render device after time tis.

As noted above, the one or more subsequent PPDUs are associated with athird priority (which is associated with a third backoff counter value(third BO value) or a third set of EDCA parameters). In this manner, theBO counter of the render device may be set to the third BO value (andthe render device may be configured for the third set of EDCAparameters), and the BO counter begins to count down to 0 at the end ofthe BA on the wireless medium (time tis). The BO counter reaches 0 attime t₁₉, and the render device provides a new RTS frame at time t₁₉. Asdepicted, time t₁₉ is still in the original NAV protection duration. Thenew RTS may indicate a new NAV value indicating an extended NAVprotection (which may be similar in duration to the original NAVprotection). In this manner, each receiving device's NAV is reset to theindicated NAV value, effectively extending the reservation of the NAV bythe render device. The new RTS frame also may indicate a new TXOP.

The end of the RTS frame on the wireless medium is at time t₂₀. Thedisplay device sends a CTS frame to the render device a SIFS durationafter time t₂₀ (time t₂₁), with the end of the CTS frame on the wirelessmedium at time t₂₂. The render device sends an N+1th PPDU to the displaydevice a SIFS duration after time t₂₂ (time t₂₃). The process may berepeated similar to the first TXOP for one or more additional TXOPs.

In some implementations, the RTS/CTS mechanism may be enabled by therender device for the first PPDU of each video frame and disabled forother PPDUs of the video frame. In this manner, the N+1th PPDU may besent without the RTS/CTS mechanism (such as to indicate a new TXOP tothe display device). The NAV duration may be extended using the NAVpadding indicated in each PPDU. In some implementations, the RTS/CTSmechanism may be enabled by the render device for PPDUs other than thefirst PPDU (such as for the one or more subsequent PPDUs, as depicted inFIG. 10 , to indicate anew TXOP).

The render device may include a video queue to receive MSDUs The MSDUsinclude descriptors to indicate a specific video frame to which the MSDUis associated. In some implementations, the render device provides theMSDUs (in one or more PPDUs) to the display device, and the one or moreobtained BAs indicate the MSDUs received by the display device. Therender device removes the identified MSDUs from the video queue untilall MSDUs are provided to the display device. In some implementations,an MSDU associated with a next video frame may be received at the videoqueue before all MSDUs associated with a current video frame aresuccessfully provided to the display device. In some implementations,the render device may flush the video queue (skipping the remainder ofthe current video frame) to begin sending MSDUs of the next video frame.In some implementations, the render device may provide the remainingMSDUs of the current video frame.

As noted above, the render device may configure itself for a firstpriority of a first PPDU of a video frame. In some implementations, therender device may adjust one or more of the EDCA parameters (and the BOvalue), whether the RTS/CTS mechanism is enabled, or the number ofretries for RTS/CTS. For example, if the video queue is empty andreceives a first MSDU associated with a second video frame, the renderdevice may configure itself for the first set of EDCA parameters (whichmay be associated with a first PPDU of a video frame) and set the BOcounter to the first BO value. If RTS/CTS is enabled for only the firstPPDU of a video frame, the render device may enable RTS/CTS (with thefirst MSDU to be included in the first PPDU of the video frame). Inaddition or to the alternative, the render device may set the number ofretries for RTS/CTS to a defined number (such as five retries). Therender device may adjust the EDCA parameters (and the BO value) to thoseassociated with the third priority after transmission of the RTS iscompleted (such as based on obtaining the CTS) or after the definednumber of retries. In some implementations, the render device maydisable RTS/CTS or adjust the number of retries for RTS/CTS aftertransmission of the RTS is completed (such as based on obtaining theCTS) or after the defined number of retries.

The first MSDU may include metadata identifying the first MSDU in thefirst PPDU of a video frame (such as in a subframe header 422 of an MSDUsubframe 416 as depicted in FIG. 4 ). The display device obtaining andprocessing the first PPDU may determine that the PPDU includes MSDUs(including the first MSDU) associated with a new video frame based onthe metadata. In some implementations, the last MSDU may includemetadata identifying the last MSDU in a last PPDU of a video frame (suchas in a subframe header 422 of an MSDU subframe 416 as depicted in FIG.4 ). The display device obtaining and processing the PPDU may determinethat the PPDU includes the last MSDU associated with a video frame basedon the metadata. The render device may prevent including an indicationof NAV padding in the last PPDU or otherwise use the last PPDU to extendthe NAV. In this manner, the render device may release control of thewireless medium at the end of the present NAV. In addition or to thealternative, the render device may send a contention free (CF)-Endbeacon after providing the last MSDU to indicate to receiving devices toclear their NAVs. In this manner, the render device may release controlof the wireless medium before the end of the present NAV.

In some implementations, the render device may shorten one or more TXOPs(such as the first TXOP) from a maximum duration. The render device mayshorten the TXOP to ensure that the display device may provide UL datato the render device at a sufficient frequency for the XR experience.Shortening the TXOP also may allow the display device to conserve powerby placing one or more components of the WCD into a lower power mode fortimes outside of the TXOP.

A device (such as the render device) and a second device (such as thedisplay device) may be in a first BSS. While not shown in FIG. 10 , adevice from an OBSS may share the wireless medium with the render deviceand the display device. Based on the first, second, and thirdpriorities, the OBSS device may be prevented from obtaining control ofthe wireless medium to transmit some types of data. For example, theOBSS device may classify its traffic as best effort, high priority, andso on. The data to be transmitted by the OBSS device is associated witha fourth priority (which may be associated with a fourth set of EDCAparameters or a fourth BO value for the OBSS device based on theclassification of the traffic). The OBSS device may contend for thewireless medium to transmit the data associated with the fourthpriority.

The render device always may obtain control to transmit the first PPDUbased on the first priority. For example, the first set of EDCAparameters (associated with the first priority) causes the render deviceto have preference over the display device and the OBSS device inobtaining control of the wireless medium. If the data associated withthe fourth priority is classified as best effort data, the render device(to transmit subsequent PPDUs associated with a third priority) and thedisplay device (to transmit data associated with a second priority) mayhave preference over the OBSS device. For example, the EDCA parametersassociated with the fourth priority may prevent the OBSS device fromtransmitting the best effort classified data.

In some implementations, the third set of EDCA parameters may beconfigured so that a device is able to transmit high importanceclassified data (which may be associated with a set of EDCA parametersto allow transmission before transmission of one or more subsequentPPDUs from the render device). For example, referring back to FIG. 10 ,if a device that did not receive the RTS is to transmit high importanceclassified data (such as based on a differentiated services code point(DSCP) value), the device may be able (based on its EDCA parametersassociated with the DSCP value) to transmit the data after time tis andbefore the render device is to send the next RTS (which is associatedwith the third set of EDCA parameters). If the device is to transmitbest effort classified data (such as based on the DSCP value), the EDCAparameters of the device associated with the DSCP value may prevent thedevice from preempting the render device from sending the RTS associatedwith the third set of EDCA parameters. The device may attempt totransmit such data (or high importance classified data) at the end ofthe NAV time.

The above examples depict operations of a render device and a displaydevice for asynchronous channel access control. In some implementations,the wireless system may be configured for synchronous channel accesscontrol. Example aspects for synchronous channel access control aredescribed below. In some implementations, synchronous channel accesscontrol is based on target wake time (TWT) sessions defined by one ormore APs (such as by one or more 802.11 ax enabled or later APs,including IEEE 802.11be and other IEEE standards subsequent to IEEE802.11ax). In some implementations, synchronous channel access controlmay be based on synchronized transmission/reception windows (which maynot conform to TWT sessions defined in the IEEE 802.11ax standard)coordinated by one or more APs (such as a pre-802.11ax AP (which alsomay be referred to as a legacy AP)).

A TWT session may be between the display device (which may be referredto as a STA regarding the TWT session characteristics) and the renderdevice (which may be referred to as a AP regarding the TWT sessioncharacteristics). The TWT session includes one or more TWT serviceperiods (SPs) during which the display device is to remain awake unlessdetermined that no further traffic is to be communicated during the SP.A TWT SP may be referred to herein as a TWT window or a window.

A TWT session (also referred to as a TWT) may include a plurality ofcharacteristics. The characteristics include:

-   -   whether an individual TWT (between two specific devices) or a        broadcast TWT (between more than two devices or devices that may        change during the TWT);    -   whether a solicited TWT (STA initiates the TWT with the AP,        which the AP may accept, reject, or provide an alternative) or        an unsolicited TWT (AP sends unsolicited TWT responses based on        a known cycle when the STA is listening to the wireless medium);    -   whether an announced TWT (STA indicates when awake in a TWT SP        (such as via a power save (PS)-Poll or an automatic power save        delivery (APSD) trigger frame) before the AP can send DL        traffic) or an unannounced TWT (AP can send DL traffic without        waiting for an indication from the STA during the TWT SP);    -   whether a trigger-enabled TWT (AP sends a trigger frame to STA        before STA can send UL traffic) or a non-trigger-enabled TWT        (STA can send UL traffic without waiting for a trigger frame);        and    -   whether an implicit TWT (STA calculates a next TWT SP start time        a fixed amount of time from a current TWT SP start time) or an        explicit TWT (STA requests the next TWT SP start time from the        AP).

A TWT for synchronous channel access control between a render device anda display device (such as for an XR experience) may be an individualTWT, solicited TWT, announced TWT, non-trigger-enabled TWT, and implicitTWT. In some implementations, the TWT is an unsolicited TWT. The TWT mayinclude such characteristics to protect XR activity of the render deviceand the display device. For example, an individual TWT ensures that theTWT window is set up exclusively for the render device and the displaydevice to communicate DL traffic (and UL traffic) between each other, asolicited TWT and an announced TWT ensures that the display device isready to receive DL traffic from the render device (to prevent delaysassociated with retries as a result of the display device not ready toreceive DL traffic), a non-trigger-enabled TWT allows the display deviceto send pose data frames at a greater frequency (without requiring theoverhead of trigger frames from the render device), and an implicit TWTreduces overhead caused by the display device requesting (and the renderdevice providing) the next TWT SP start time. While an example set ofcharacteristics for a TWT is indicated, any suitable set ofcharacteristics may be used.

As used herein, XR activity may refer to any actions performed by one ormore devices (such as one or more of a render device or a displaydevice) to provide the XR experience to the user. The XR activity mayinclude measuring the position of the display device by the IMU of thedisplay device, generating the pose frames or packets (also referred toas pose data frames) from the IMU measurements, generating trackingframes, providing pose frames and tracking frames to the render device,rendering and encoding one or more video frames based on the pose framesand tracking frames, packetizing the one or more video frames, providingthe packets to the display device, decoding the video frames from thereceived packets, processing the video frames (such as de-jitter andATW), and displaying the video frames. XR activity additionally oralternatively may include operations to provide audio, haptic feedback,or other sensory information to the user during the XR experience.

Similar to asynchronous channel control access described above,synchronous channel control access using TWT is to prevent collisionsand interference on the wireless medium by aligning the traffic betweenthe render device and the display device to meet the latency and packetloss requirements for the XR experience. UL traffic may be sent by thedisplay device when available (including outside of the TWT windows). Insome implementations, though, the UL traffic is transmitted during theTWT windows. As noted above, for an XR experience, UL traffic mayinclude pose frames and tracking frames from the display device. DLtraffic may include PPDUs carrying video frame data from the renderdevice. The PPDUs, pose frames, and tracking frames are transmittedduring the TWT windows, and data from other devices (or other data fromthe render device to the AP or other devices) is transmitted outside ofthe TWT windows. To note, the concepts described herein may be appliedto other types of UL traffic and DL traffic (such as an application filenot being associated with video) and other types of devices. Someaspects of the disclosure are described in examples with reference to arender device and a display device for an XR experience for clarity indescribing the aspects, but the aspects of the disclosure are notlimited to the provided examples.

Referring back to FIG. 7 , the rendering and encoding of each videoframe (710) by the render device may be at a known interval andperiodicity associated with the frame rate of the display (720). The TWTwindows for the TWT session between the render device and the displaydevice may be setup to have a known interval based on the known intervaland periodicity for rendering. For example, the render device may beready to transmit PPDUs of a next video frame at a known periodicity,and timing of the TWT windows may be based on the periodicity. As notedabove, the TWT windows include the time that the wireless medium isallocated for UL and DL data to be transmitted between the render deviceand the display device. In this manner, when UL traffic is to betransmitted by the display device may be coordinated with when DLtraffic is to be transmitted so that both may be transmitted during theTWT windows. The render device may setup the TWT session with thedisplay device based on the rendering of video frames at the renderingdevice (with the period and length of the TWT windows indicated to thedisplay device). The display device may coordinate transmitting ULtraffic based on the indicated period and length of the TWT windows. Thelength of the TWT windows allows both UL traffic and DL traffic (alsoreferred to as UL data and DL data, respectively) to be transmittedduring a same TWT window.

FIG. 11 shows a flowchart illustrating an example process 1100 forsynchronous channel access control based on a TWT session according tosome implementations. The operations in the example process may beperformed by a device (such as the device 154 in FIG. 1B) or a wirelesscommunication device implemented in the device (such as the WCD 615 inFIG. 6B). The device performing the operations may be a render device ofan XR experience.

At 1102, the device obtains UL data from a second device over a wirelessmedium. The UL data may include one or more pose frames or one or moretracking frames from the second device, which may be a display device(such as a HMD).

At 1104, the device provides, to the second device, DL data includingPPDUs over the wireless medium. The PPDUs may include video frame data.During a current TWT window, the device may provide one or more of thePPDUs to the second device (1106). One or more pose frames also may beobtained during the current TWT window. In this manner, both UL data andDL data may be transmitted during the current TWT window.

The beginning time of the TWT windows may be adjusted to reduce latencyand increase efficiency in using TWT windows. For example, if the TWTwindow begins an amount of time before either UL data or DL data istransmitted during the TWT window, the second device (such as a displaydevice) is to remain awake and listening for the amount of time of theTWT window not used for transmissions. In addition, if the PPDUs areready for transmission outside of the TWT windows, the render devicemust wait until a next TWT window to transmit the PPDUs. If UL data isto be transmitted outside of the TWT windows, the display device mustremain in an active power state during times outside of the TWT windowsto transmit the UL data. As noted above, the periodicity of renderingvideo frames is known (with when PPDUs for the video frames beingavailable for transmission being periodic). If the time at which thePPDUs (such as the first PPDU) are available for transmission duringeach period is known, the beginning of the TWT window may be determinedbased on when the PPDUs are available each period. In this manner, abeginning of the current TWT window is associated with one of when afirst PPDU of the one or more PPDUs is provided to the second device orwhen the first PPDU is provided from an application layer to a MAC ofthe device (1108). For example, the beginning of the current TWT window(and the other TWT windows) is synchronized with the time to transmit DLdata and UL data to reduce any latency between the beginning of the TWTwindow and transmission and to reduce any time the render device is towait between making one or more PPDUs ready for transmission andtransmitting the one or more PPDUs.

As noted above, the DL data and the UL data may be associated with videoframes rendered for an XR experience. In some implementations, thedevice depicted in FIG. 11 (such as a render device) renders videoframes to be displayed by the second device (such as display device). Inthis manner, the UL data from the second device includes pose dataframes, and the rendering of the video frames is associated with theobtained pose data frames. As noted above, video frames (such as a firstvideo frame) includes a plurality of video slices, rendering of thefirst video frame is associated with a pose data frame most recentlyobtained from the second device, and one or more PPDUs to be transmittedto the second device are associated with one or more of the plurality ofvideo slices. For example, a render device splits a video frame into aplurality of slices, and the render device packages each slice into aplurality of PPDUs to be transmitted during the TWT windows. Each TWTwindow may be used by the render device to transmit a video frame'sPPDUs to the display device (with the next TWT window used to transmitthe next video frame's PPDUs).

The second device listens for DL data during the TWT windows. If thetransmission of DL data and UL data is coordinated so that both aretransmitted during the TWT windows, the second device may not need totransmit outside of the TWT windows. The second device (such as adisplay device) may enter a low power mode (such as powering down orreducing power to one or more components of its wireless communicationdevice) between TWT windows. In this manner, the second device mayreduce power consumption. For example, many display devices (such asHMDs) are battery powered to allow a user to move about and not restricta user's freedom of movement. The display device may place one or morecomponents of its radio frequency (RF) front end into a low power modebetween TWT windows to conserve power and extend the amount of time thedisplay device may be in use between charges. Such a low power modeduring a TWT session may be referred to as a TWT power save mode.

The render device may determine to continue to transmit to the displaydevice outside of the TWT windows. For example, the render device maydetermine that one or more PPDUs of a video frame cannot be provided tothe display device during the current TWT window. In this manner, theone or more PPDUs may be provided after the current TWT window. In someimplementations, the render device may provide an indication to thedisplay device not to enter into a low power mode (TWT power save mode)after the current TWT window. The indication may be included in a powermanagement (PM) field of a packet's MAC header (such as a PM bit of theframe control field being set to 0 to indicate that the display deviceis not to enter into the low power mode) provided to the display deviceduring the current TWT window (such as the last packet provided to thedisplay device during the window). The display device processes thepacket's header and determines that entering the low power mode is to beprevented after the current TWT window. In this manner, the renderdevice may provide, to the display device, a PPDU after the current TWTwindow and before a next TWT window.

Conversely, the render device may terminate a current TWT window earlyif no additional PPDUs are to be transmitted during the current TWTwindow. For example, if all PPDUs of a video frame are provided to thedisplay device before the end of the current TWT window, the renderdevice may indicate to the display device that the current TWT window isbeing ended early. In some implementations, the end of service period(EOSP) bit of the Quality of Service (QoS) field of the MAC header of apacket may be set to 1 to indicate that the TWT window is ending. Thepacket may include a null data frame and be used exclusively to indicatethe end of the TWT window via the QoS field's EOSP bit (which may bereferred to as an EOSP packet). As defined for TWT sessions (such as inthe IEEE 802.11ax standard), an EOSP packet can be sent after more than10 ms of inactivity during the TWT window. In some implementations, therender device is configured to send the EOSP packet after 10 ms ofinactivity after the last PPDU.

In some implementations, the TWT window may end before 10 ms ofinactivity has elapsed. For example, as noted above, an MSDU may includemetadata to indicate the MSDU being the last MSDU for the video frame.In processing the last MSDU, the display device determines that no morePPDUs are to be received from the render device for the video frame, andthe display device may enter a low power mode until the next TWT window(effectively ending the TWT window for the display device). In anotherexample, the render device may be configured to send the EOSP packetafter less than 10 ms of inactivity (such as immediately after the lastPPDU). The render device may determine to send the EOSP packet based onthe metadata of the last MSDU when preparing the PPDUs for transmissionto the display device.

The low power mode (TWT power save mode) referred to herein may differfrom one or more sleep modes defined in the IEEE 802.11 standard (suchas pre-802.11ax standards, including 802.11ba, etc.). For example, thelow power mode (TWT power save mode) may be associated with a fastersleep to wake (S2 W) and wake to sleep (W2S) time than the standarddefined sleep mode (referred to as deep sleep) designed for best effortclassified traffic based on delivery traffic indication messages (DTIMs)in an AP's beacons. In some implementations, the smallest low powerperiod (including S2 W and W2S) for the low power mode may beapproximately 10 ms, and the smallest deep sleep period (including S2 Wand W2S) for deep sleep may be approximately 40 ms (which may be toolong for XR activity for video at 60 fps (approximately 16 ms per videoframe)). The low power mode may differ from deep sleep by powering downfewer RF front end components, maintaining a carrier signal lock of thewireless medium, or other operations to reduce the amount of time toenter into and exit from the low power mode.

FIG. 11 depicts an example process from the render device perspective.FIG. 12 depicts the example process from the display device perspective.

FIG. 12 shows a flowchart illustrating an example process 1200 forsynchronous channel access control based on a TWT session according tosome implementations. Operations in the example process may be performedby a device (such as the device 152 in FIG. 1B) or a wirelesscommunication device implemented in the device (such as the WCD 615 inFIG. 6B). The device performing the operations may be a display deviceof an XR experience.

At 1202, the device provides UL data to a second device over a wirelessmedium. The second device may be a render device, and the UL data mayinclude one or more of a pose data frame or a tracking frame.

At 1204, the device obtains, from the second device, DL data includingPPDUs over the wireless medium. For example, the PPDUs are associatedwith one or more video frames rendered based on the UL data. The deviceobtains one or more PPDUs from the second device during a current TWTwindow (1206), and a beginning of the current TWT window is associatedwith one of when a first PPDU of the one or more PPDUs is provided tothe device or when the first PPDU is provided from an application layerto a MAC of the second device (1208).

As noted above, the beginning of a TWT window is associated with when afirst PPDU is to be transmitted. In some implementations, the beginningof the TWT window may coincide with when the first PPDU is to betransmitted. In some implementations, the TWT window may begin beforewhen the first PPDU is to be transmitted. The display device may provideone or more of a tracking frame or one or more pose data frames for eachvideo frame to be rendered. In this manner, the frequency of providingthe tracking frames or one or more pose data frames is the same as thefrequency of the video frames. For example, the pose data frames may beprovided at a first frequency, and the video frames may be rendered atthe first frequency. The display device may provide a pose data framebefore when the first PPDU of a video frame is ready for transmission.In some implementations, a TWT window begins when the tracking frame ora first of one or more pose data frames is to be transmitted from thedisplay device to the render device. For example, when the TWT window isto begin may be based on a M2R latency for the XR experience.

FIG. 13 shows a sequence diagram 1300 illustrating example timings ofpose data frames and rendering of video frames associated with a M2Rlatency. At 1302, the display device obtains pose information. Forexample, the display device determines to package the current IMUmeasurement into a pose data frame N−1 (for any integer N greater than0) and provide the pose data frame N−1 to the render device. UL latency1304 is the latency between the time of the IMU measurement to the timethe render device obtains the pose data frame N−1 (at 1306). UL latency1304 may vary based on the amount of UL data to transmit and theconditions of the wireless medium. For example, if the wireless mediumincludes more interference or noise, the UL latency 1304 may be greateras a result of retries in sending the pose frame N−1 or using a lowerMCS rate to transmit the pose frame N−1. After obtaining the pose frameN−1 (1306), the render device begins rendering video frame N−1 (1308).Time 1310 indicates the rendering time to render video frame N−1. Whilenot depicted, the rendering time may include time for rendering andencoding of the video frame. The render device provides video frame N−1to the display device in a plurality of PPDUs. Time 1312 is the timeduring which the PPDUs are provided from the render device to thedisplay device. While not shown, the PPDUs may be provided before orafter encoding of the entire frame is completed. For example, a videoslice may be packaged into one or more PPDUs concurrently with anothervideo slice being processed before packaging into one or more PPDUs. Inthis manner, time 1312 may overlap time 1310.

At 1316, the display device again obtains pose information. For example,the display device determines to package the current IMU measurement atthat time into pose data frame N. The pose data frame N is obtained bythe render device at time 1320 (with the UL latency 1318 being thelatency between time 1316 and time 1320). UL latency 1318 is depicted asbeing greater than UL latency 1304 to depict that UL latencies may vary.

At 1322, the render device begins rendering video frame N. The video mayhave a specific frame rate, and the interval between video framerenderings may be fixed based on the frame rate, resolution, encoding,and other video parameters. In this manner, the amount of time betweentimes 1308 and 1322 may be the same as the amount of time between time1322 and a time to begin rendering video frame N+1. Time 1324 indicatesthe rendering time to render video frame N. The render device providesvideo frame N to the display device in a plurality of PPDUs. Time 1326is the time during which the PPDUs are provided from the render deviceto the display device. While not shown, times 1312 and 1326 may bevariable based on channel conditions, channel size, MCS, use of forwarderror correction (FEC), number of PPDUs to be transmitted, or othercharacteristics.

The render device renders a current frame based on the most recent poseframe obtained from the display device. For video frame N, time 1322 isbefore time 1320 (when pose frame N is obtained). In this manner, therender device does not render video frame N based on pose frame N (sincepose frame N is not yet obtained). If the last pose frame obtained ispose frame N−1, the render device renders video frame N based on poseframe N−1. The M2R latency may be a latency between the IMU measurementand rendering a video frame associated with the IMU measurement. Sincevideo frame N is based on pose frame N−1, the M2R latency 1314 is largerthan if pose frame N would be received in time. The M2R latency may bedetermined based on a predefined or known UL latency.

In some implementations, a TWT window 1328 may begin at time 1302(assuming that time 1302 is when the display device is to transmit thepose frame N−1). If the amount of time between times 1302 and 1316 isfixed (such as the same amount of time as between times 1308 and 1322),the length of the TWT window 1328 may be fixed to include through time1312. Since time 1312 may vary, the TWT window 1328 may be of a lengthto accommodate variations in the time 1312 (such as a length to allowtransmission of the video frame based on a maximum resolution, minimumMCS, minimum channel size, and so on). As noted above, the render devicealso may indicate that one or more PPDUs are to be transmitted after theend of a TWT window to transmit PPDUs unable to be transmitted duringthe TWT window. In the example, the end of the TWT window 1328 may bebetween the end of time 1312 and time 1316. While not shown, a new TWTwindow may begin at time 1316. To note, the sequence diagram 1300 (andother sequence diagrams depicted) are not to scale and may vary inoperations. For example, the DL of video frame N−1 (1312) can betogether with the UL of pose frame N (1320) into one TWT window.

In the example sequence diagram 1300, timing of providing pose framesand rendering video frames is not coordinated, which may cause a videoframe to be rendered before receiving a new pose data frame and increasethe M2R latency. The render device may coordinate rendering of videoframes or the display device may coordinate providing pose frames to therender device so that one or more pose frames are obtained beforerendering a new video frame (such as the render device and the displaydevice coordinating so that time 1322 occurs after time 1320). FIG. 14depicts timings that are coordinated to reduce the M2R latency.

FIG. 14 shows a sequence diagram 1400 illustrating example timings ofpose data frames and rendering of video frames associated with a M2Rlatency. At 1402, the display device obtains pose information. Forexample, the display device determines to package the current IMUmeasurement into a pose data frame N−1 (for any integer N greater than0) and provide the pose data frame N−1 to the render device. UL latency1404 is the amount of time from the time of the IMU measurement to thetime the render device obtains the pose frame N−1 (at 1406). UL latency1404 may vary based on the amount of information to transmit and theconditions of the wireless medium. For example, if the wireless mediumincludes more interference or noise, the UL latency 1404 may be greateras a result of retries in sending the pose frame N−1 or using a lowerMCS rate to transmit the pose frame N−1. After obtaining the pose frameN−1 (1406), the render device begins rendering video frame N−1 (1408).Time 1410 indicates the rendering time to render video frame N−1. Therender device provides video frame N−1 to the display device in aplurality of PPDUs. Time 1412 is the time during which the PPDUs areprovided from the render device to the display device.

At 1416, the display device obtains pose information and provides thepose data frame N to the render device. UL latency 1418 is the amount oftime from the time of the IMU measurement to the time the render deviceobtains the pose data frame N (at 1420). UL latency 1418 for pose frameN is greater than UL latency 1404 to depict that UL latencies may vary.At 1422, the display device begins rendering video frame N. Time 1424indicates the rendering time to render video frame N. The render deviceprovides video frame N to the display device in a plurality of PPDUs.Time 1426 is the time during which the PPDUs are provided from therender device to the display device. TWT window 1428 may be the same asTWT window 1328 in FIG. 13 .

The amount of time between times 1408 and 1422 may be the same as theamount of time between 1308 and 1322 in FIG. 13 . The difference betweenFIGS. 13 and 14 may be the timing between providing pose frames by thedisplay device and rendering video frames by the render device. Asdepicted in FIG. 14 , a timing of rendering the video frames iscoordinated with a timing of the display device providing the poseframes to the render device. For example, time 1422 is determined sothat time 1422 remains after time 1420. In this manner, pose frame N isobtained before rendering video frame N, and pose frame N may be used torender video frame N. In some implementations, the timing may be basedon an UL latency for the pose frames (such as a potential UL latencybased on the lowest MCS, smallest wireless channel, a level of noise,use of FEC, and other parameters to slow throughput of transmitting thepose data frame to the render device). With rendering being coordinated,the M2R latency 1414 is reduced. For example, the M2R latency 1414 isless than the M2R latency 1314 in FIG. 13 .

If rendering and providing the pose frames are coordinated, thebeginning of the TWT windows may be based on the M2R latency. Forexample, the render device may determine a TWT window to begin a firstoffset before the time to render a video frame. In some implementations,the first offset may be the M2R latency (such as M2R latency 1414 beforetime 1408 to be the beginning of the TWT window 1428).

As depicted in FIGS. 13 and 14 , pose data frames may be obtained orprovided and video frames may be rendered at the same frequency. In someimplementations, more than one pose data frame may be provided during aTWT window (such as providing a pose data frame in the middle or towardsthe end of the TWT window), but at least the pose data frames providedat the beginning of the TWT windows may be provided at the firstfrequency. In this manner, each of the pose data frames obtained at thebeginning of the TWT windows may be associated with a rendered videoframe. Additional pose data frames may be provided during a TWT windowin case there are issues obtaining the first pose data frame during theTWT window (such as based on temporary interference on the wirelessmedium). For example, if pose frame N is not obtained by the renderdevice in FIG. 14 , but the display device provides an intermediate poseframe at the end of the TWT window 1428, the render frame may use theintermediate pose frame (instead of pose frame N−1) to render videoframe N. Providing additional pose frames may reduce the latency betweenwhen the pose information was obtained and when the video frame isrendered in such instances.

Referring back to the pose frames provided at the beginning of the TWTwindows, obtaining the pose frames and rendering the video frames are atthe same frequency, and timing between rendering video frames andobtaining pose frames is coordinated to reduce the M2R latency.Obtaining pose information is performed at an application layer of thedisplay device, and rendering video frames is performed at anapplication layer of the render device. Referring back to FIGS. 6A and6B, the application processor 630 (in conjunction with the memory 640)may execute an XR application on the render device (such as a VR or ARapplication on a smartphone). The application processor 635 (inconjunction with the memory 645) may execute an XR application of thedisplay device (such as a VR or AR application on a HMD). At theapplication layer, the render device renders the video frames orgenerates audio, haptic feedback, or other information for the XRexperience, and the display device obtains IMU measurements (such asfrom the sensors 675), displays the video, plays the audio, or providesother information to the user for the XR experience. Operations at theapplication layer are based on an application layer clock of the device.For example, the device may use a first piezoelectric material (such asa crystal) to generate a host clock provided to the applicationprocessor for performing application layer operations. In this manner,the application layer clock is used by the device for timing ofrendering video frames (by the render device) or for timing ofdisplaying the video frames (by the display device). Such a clock may bereferred to as the application layer clock.

As noted above, the WCD 610 or 615 is used to perform operations at thelower layers of the OSI model (such as at the MAC). For example,managing and scheduling pose data frames, tracking frames, or PPDUs fortransmission and managing receipt of packets may be at the MAC andmanaged by the WCD 610 or the WCD 615. Operation of the WCD is based ona second clock (referred to as the WCD clock). The WCD clock is used bythe device for timing of wireless communications with a second device.The WCD clock is based on a second piezoelectric material (such as asecond crystal) of the device different than for the application layerclock. Since a device may use two different crystals (and thus differentlogic) to generate the application layer clock and the WCD clock, theapplication layer clock and the WCD clock may be at differentfrequencies, resolution, or phases.

To coordinate timing between providing pose frames (and tracking frames)and rendering video frames, the display device and the render device maysynchronize the application layer clock and the WCD clock. In thismanner, the application layer clock and the WCD clock may have the samefrequency and phase. In some implementations, the application layerclock may be synchronized to the WCD clock. In some implementations, theWCD clock may be synchronized to the application layer clock. The clocksof one device also may be synchronized to the clocks of the otherdevice. In this manner, one of the four clocks between the render deviceand the display device is the reference clock, and the other threeclocks are synchronized to the reference clock. The TWT window timings(such as offsets used to determine the beginning of a TWT window) may bedetermined based on the reference clock. The application layer clock ofthe display device may drive timing of the TWT windows if the displaydevice's application layer clock is the reference clock, or theapplication layer clock of the render device may drive timing of the TWTwindows if the render device's application layer clock is the referenceclock. If the WCD clock is to be used to synchronize the other clocks, aschedule of the TWT windows may be set, and one or more of the rendertiming or the display timing of video frames may be adjusted based onthe set schedule of TWTs.

FIGS. 15A-15C depict different clocks being the reference clock forsynchronization. The application layer clock of the display device isdepicted as the reference clock in FIG. 15A, the application layer ofthe render device is depicted as the reference clock in FIG. 15B, andthe WCD clock of the render device or the display device is depicted asthe reference clock in FIG. 15C.

FIG. 15A shows a block diagram 1500 illustrating an example ofsynchronizing the clocks of the render device 1502 and the displaydevice 1508. The render device 1502 includes the application layer clock1504 and the WCD clock 1506, and the display device 1508 includes theapplication layer clock 1510 and the WCD clock 1512. In the example, theapplication layer clock 1510 is the reference clock, and the otherclocks are synchronized to the application layer clock 1510.

At 1514, the WCD clock 1512 is synchronized to the application layerclock 1510. For example, a time of the application layer clock 1510 maybe indicated in the pose information or tracking frames to be providedto the render device 1502. The information is provided from theapplication layer to the MAC (such as to the WCD) to be scheduled andtransmitted to the render device 1502. The WCD may obtain the time fromthe obtained information from the application layer and synchronize theWCD clock based on the indicated time.

At 1516, the WCD clock 1506 synchronizes to the WCD clock 1512.

For example, the WCD of the display device 1508 includes a local timingsynchronization function (TSF) timer for synchronizing communicationsover the wireless medium with the render device 1502. The WCD of therender device 1502 also includes a local TSF timer. The WCD of thedisplay device 1508 periodically provides an indication of its TSF timervalue to the WCD of the render device 1502 (such as via the pose dataframes or via a beacon frame from the display device 1508 to the renderdevice 1502). Synchronizing the WCD clock 1512 to the application layerclock 1510 causes the TSF timer of the WCD of the display device 1508 tobe adjusted. Since an indication of the TSF timer value is periodicallyprovided to the WCD of the render device 1502, the adjusted TSF timervalue is indicated to the WCD of the render device 1502. The renderdevice 1502 may adjust its WCD clock based on the adjusted TSF timervalues from the display device 1508.

With the WCD clock 1506 of the render device 1502 synchronized to theWCD clock 1512 and the application layer clock 1510 of the displaydevice 1508, the render device 1502 may synchronize the applicationlayer clock 1504 to the WCD clock 1506 (1518). In some implementations,the render device 1502 may be configured to make the TSF timer valuesavailable to the application layer (such as via a call from the MAC tothe application layer configured for the render device 1502). If the TSFtimer is not visible at the application layer, the timing informationfrom the packets obtained from the display device (such as the indicatedTSF timer values and the times at which the packets are transmitted) maybe used in synchronizing the application layer clock 1504.

FIG. 15B shows a block diagram 1520 illustrating an example ofsynchronizing the clocks of the render device 1522 and the displaydevice 1528. The render device 1522 includes the application layer clock1524 and the WCD clock 1526, and the display device 1528 includes theapplication layer clock 1530 and the WCD clock 1532. In the example, theapplication layer clock 1524 is the reference clock, and the otherclocks are synchronized to the application layer clock 1524.

At 1534, the WCD clock 1526 is synchronized to the application layerclock 1524. For example, a time of the application layer clock 1524 maybe indicated in the video frames or other information to be provided tothe display device 1528. The information is provided from theapplication layer to the MAC (such as to the WCD) to be scheduled andtransmitted to the display device 1528. The WCD may obtain the time fromthe obtained information from the application layer and synchronize theWCD clock based on the indicated time.

At 1536, the WCD clock 1532 synchronizes to the WCD clock 1526 (such asbased on the local TSF timer values of the WCD of the render device1522). For example, the WCD of the render device 1522 periodicallyprovides an indication of its TSF timer value or other timinginformation to the WCD of the render device 1502 (such as via one ormore MAC control elements (CEs) of the PPDUs for the video frames), andthe local TSF timer of the display device 1528 may be adjusted based onupdated timing information after synchronizing the WCD clock 1526 to theapplication layer clock 1524. With the WCD clock 1532 of the displaydevice 1528 synchronized to the WCD clock 1526 and the application layerclock 1524 of the render device 1522, the display device 1528 maysynchronize the application layer clock 1530 to the WCD clock 1532(1538). Similar to as described above with reference to FIG. 15A, thedisplay device 1528 may be configured to make the TSF timer valuesavailable to the application layer (such as via a call from the MAC tothe application layer configured for the display device 1528). If theTSF timer is not visible at the application layer, the timinginformation from the packets obtained from the render device (such asthe indicated TSF timer values and the times at which the packets aretransmitted) may be used in synchronizing the application layer clock1530.

FIG. 15C shows a block diagram 1540 illustrating an example ofsynchronizing the clocks of the render device 1542 and the displaydevice 1548. The render device 1542 includes the application layer clock1544 and the WCD clock 1546, and the display device 1548 includes theapplication layer clock 1550 and the WCD clock 1552. In the example, theWCD clock 1546 or 1552 is the reference clock, and the other clocks aresynchronized to the WCD clock.

At 1554, the WCD clocks 1546 and 1552 are synchronized to each other.For example, the TSF timers between the devices may be synchronized,with timing information provided between the devices (such as describedabove with reference to FIGS. 15A and 15B). At 1556, the render device1542 synchronizes the application layer clock 1544 to the WCD clock 1546(such as described above with reference to FIG. 15A). At 1558, thedisplay device 1548 synchronizes the application layer clock 1550 to theWCD clock 1552 (such as described above with reference to FIG. 15B).

Referring back to FIG. 15A, if the application layer clock 1510 is thereference clock, the application layer clock 1510 initially may be setby the display device 1508 and not need to be adjusted during operation.Since the application layer clock 1510 is not adjusted during operationand display of the video frames is based on the application layer clock1510 of the display device 1508, display of the video frames may remainconstant during operation (with other clocks 1504, 1506, and 1512 beingadjusted to remain synchronized to the application layer clock 1510).The display device 1508 may determine the TWT session schedule betweenthe render device 1502 and the display device 1508. The schedule mayinclude the interval of the TWT windows, the size of the TWT windows,and the start times of the TWT windows. The display device 1508 mayalign UL traffic to the TWT windows (such as aligning the transmissionof pose frames to the beginning of the TWT windows). In this manner, thetiming of pose information being packaged and provided to the renderdevice 1502 is based on the TWT schedule that is determined based on theapplication layer clock 1510. For example, the specific IMU measurementsthat are to be used to generate pose frames may be based on the TWTschedule that is determined based on the application layer clock 1510.

With the WCD clock 1506 and the application layer clock 1504synchronized to the application layer clock 1510, the render device 1502may align DL traffic to the TWT windows (such as aligning thetransmission of the PPDUs to a portion of the TWT windows). For example,referring back to FIG. 14 , the display device determines the times 1402and 1416 to be at the beginning of the TWT windows (including TWT window1428) based on the TWT schedule. The render device may coordinate times1408 and 1422 (to render video frames N−1 and N) to be a first offsetfrom times 1402 and 1416, respectively (with the first offset associatedwith the M2R latency). As noted above, M2R latency 1414 may be known.The first offset may be the M2R latency 1414. In this manner, the renderdevice may coordinate time 1410 to be the M2R latency 1414 after time1402.

In some implementations, the render device may trigger times 1408 and1422 based on obtaining a pose frame during the TWT window or based on atimeout from the beginning of the TWT window. For example, triggeringrendering video frame N−1 (at time 1408) may be based on obtaining poseframe N−1 (at time 1406). In this manner, the difference between times1406 and 1408 is based on the amount of time needed to trigger renderingthe video frame (such as processing the pose frame and providing thepose information by the WCD to the application layer before renderingthe video frame at the application layer). As noted above, if the renderdevice fails to obtain the pose frame (such as based on interference onthe wireless medium), the render device does not provide an ACK to thedisplay device. The display device may retry to provide the pose frameone or more times (such as up to a maximum number of times or up to atimeout amount of time from the beginning of the TWT window). Thetimeout may be based on when the render device is to begin rendering thevideo frame. For example, a timeout time may be an amount of time up tofrom the beginning of the TWT window to the time when the render deviceis to begin rendering a video frame (such as time 1402 to 1408). Thetimeout time may be determined by the render device or may be defined inthe TWT session. In this manner, the render device begins counting fromthe beginning of each TWT window, and the render device triggersrendering the video frame at the first of reaching the timeout time orobtaining the pose frame. If a timeout occurs (with the timeout timebeing reached before obtaining the pose frame), the render device mayuse the last obtained pose frame obtained before the TWT window (such asduring the last TWT window) to generate the video frame.

In some implementations, the display device may indicate when the renderdevice is to begin rendering a video frame. In this manner, the renderdevice triggers rendering each video frame based on an explicitindication from the display device. For example, a verticalsynchronization (Vsync) value at the application layer of the displaydevice may be indicated to the WCD to indicate the time the renderdevice is to render a video frame. The time based on the Vsync may beindicated between the WCDs, and the render device may convert theindicated time to an application layer time to render the video frame.

Referring back to FIG. 15B, if the application layer clock 1524 is thereference clock, the application layer clock 1524 initially may be setby the render device 1522 and not need to be adjusted during operation.Since the application layer clock 1524 is not adjusted during operationand rendering of the video frames is based on the application layerclock 1524 of the render device 1522, rendering of the video frames mayremain constant during operation (with other clocks 1526, 1532, and 1530being adjusted to remain synchronized to the application layer clock1524). The render device 1522 may determine the TWT session schedulebetween the render device 1522 and the display device 1528. The schedulemay include the interval of the TWT windows, the size of the TWTwindows, and the start times of the TWT windows. The render device 1522may determine a start time of a TWT window to be an offset before thedefined render time for a video frame. For example, referring back toFIG. 14 , times 1408 and 1422 may be set based on the application layerclock 1530 (FIG. 15B). The render device may determine times 1402 and1416 (which are the beginning of the TWT windows) to be a first offset(associated with the M2R latency) before the set render times 1408 and1422. In some implementations, the first offset may be the M2R latency1414, such as described above. As noted above, the M2R latency (and thefirst offset) may be determined to account for UL latency.

With the WCD clock 1532 and the application layer clock 1530synchronized to the application layer clock 1524 (FIG. 15B), the displaydevice 1528 may align UL traffic to the TWT windows. For example,referring back to FIG. 14 , the display device may determine the times1402 and 1416 to be at the beginning of the TWT windows (including TWTwindow 1428) based on the TWT schedule indicated by the render device.The display device 1528 also may align the display times for the videoframes based on the application layer clock 1530. In this manner, thedisplay time of a current video frame is aligned to a time associatedwith a current TWT window.

Referring back to FIG. 15C, if the WCD clock 1546 or 1552 is thereference clock, the WCD clocks 1546 and 1552 initially may be set andsynchronized based on TSF information provided between the render device1542 and the display device 1548. For example, the render device 1542may provide timing information to the display device 1548, and the localTSF timers may be synchronized based on the timing information. In thismanner, the application layer clock 1544 and the application layer clock1550 are adjusted based on the respective WCD clock. With a WCD clock asthe reference clock, the TWT session schedule may be based on networkresource availability (in addition to the latency requirements for XRtraffic). For example, the TWT window size, interval, and start timesmay be based on the wireless medium being shared by concurrent linksfrom the render device to an AP and to the display device. In anotherexample, the TWT window size, interval, and start times may be based onthe wireless medium being shared by multiple links between the renderdevice and multiple display devices (such as in a mesh network). The TWTsession schedule may be determined either by the render device or thedisplay device, and the render device and the display device maycoordinate application layer operations based on the TWT sessionschedule.

Referring back to FIG. 14 , in some implementations, the render devicemay set times 1408 and 1422 to be a first offset after the beginning ofthe respective TWT window (such as a first offset equal to the M2Rlatency 1414 after time 1402 for time 1408). In some implementations,the render device may trigger rendering based on obtaining a pose frameor a timeout occurring (such as described above). The display device maydetermine the time to display the video frames based on the TWT sessionschedule.

Over time, the synchronized clocks may drift from one another. Therender device or the display device may periodically synchronize theclocks as a result of the drift. For example, the WCD clocks may remainsynchronized based on the TSFs, but the application layer clock at thedisplay device or the render device may drift from the respective WCDclock. In some implementations, the device measures and determines if adrift between the application layer clock and the WCD clock is greaterthan a defined threshold (such as more than 100 ρs). If the driftbecomes greater than the defined threshold, the device again maysynchronize the application layer clock and the WCD clock.Synchronization may be performed as described above with reference toFIGS. 15A-15C and based on which clock is the reference clock. If thedevice includes the reference clock, the other device also maysynchronize its clocks based on the synchronization.

In the above examples, the display device may provide more than one poseframe during a TWT window. For example, a first pose frame may beprovided at the beginning of a TWT window. The display device also mayprovide one or more additional pose frames later in the TWT window. Insome implementations, the display device may provide an additional poseframe after a defined time of inactivity on the wireless medium duringthe TWT window. In some implementations, the display device may providean additional pose frame towards the end of the TWT window or after therender device indicates that no further PPDUs are to be provided (suchas based an indication in an MSDU indicating that the MSDU is the lastMSDU for the video frame). Each pose frame may be based on a new IMUmeasurement. If a pose frame is not obtained by the render device (suchas based on interference on the wireless medium), the previous poseinformation obtained at the render device is less stale than if only onepose frame is provided per TWT window.

In some implementations, the IMU measurements occur independent frompackaging the position information as a pose frame to provide to therender device. For example, the IMU may measure the position informationat a frequency of 1 kHz (every 1 ms). The display device may use themost recent IMU measurement to generate a pose frame when needed, andthe display device may ignore the other IMU measurements for the poseframes. In this example, the latency between the IMU measurement andgenerating the pose frame is up to 1 ms. In some implementations, theIMU measurements may be based on when the pose frames are to begenerated. For example, the IMU measurements may be triggered based on atiming of providing pose frames to the render device.

With synchronous channel access, timing of communications is managed bythe render device and the display device to ensure latency requirementsare met for the XR traffic (such as to ensure a smooth display of videoframes and to ensure a M2R2P latency is met for the XR experience). Therender device may handle XR traffic differently than other traffic (suchas best effort classified traffic to another device). In this manner,handling of data and communication of such data may be based on theapplication (such as whether XR related data or not XR related data).

For best effort classified traffic, stations typically provide thetraffic at the MSDU level to a first in first out (FIFO) queue of theWCD for transmission. The management of the MSDUs in the queue iswithout concept of data delivery deadlines or latency requirements, andeach MSDU is managed independently from other MSDUs. For an XRapplication, an application file may require more than one MSDU. Inaddition, time sensitivity of delivering application data (such asdelivering a video frame within a defined amount of time) may requirethe MSDUs carrying the application data to be delivered within a definedamount of time. If any MSDUs are lost or late in being obtained by thedisplay device, all other MSDUs obtained for the application file maynot be processed and may be useless to the display device. For example,if a video slice is packaged into multiple MSDUs by the render deviceand all of the MSDUs except for one is delivered to the display device,the delivered MSDUs cannot be used to generate the video slice. In someimplementations, the render device and the display device are configuredto manage XR traffic to ensure all MSDUs of an application file aredelivered in time to comply with latency requirements for the XRexperience.

FIG. 16 shows a flowchart illustrating an example process 1600 formanaging data for transmission according to some implementations. Theexample depicts the data as video frames of a video for an XRexperience, but the data may be any suitable data of an application file(which may be for or not for an XR experience). For example, thesuitable data may be audio data, haptic data, or other data for an XRexperience. In another example, the suitable data may be other datapackaged into a plurality of MSDUs to be transmitted to a second device.The device performing the operations in process 1600 may be a renderdevice, and the second device may be a display device.

At 1602, the device renders a plurality of video frames to be providedto a second device.

At 1604, the device splits each video frame of the plurality of videoframes into a plurality of video slices. At 1606, the device generates,for each video slice, a plurality of PPDUs to include the video slice.Each PPDU includes one or more MSDUs associated with the video slice(1608). The video slice associated with the one or more MSDUs may beidentified by a port number and a DSCP value included in each MSDU(1610). The port number may be the ID of the source port to be used intransmitting the MSDU, and the DSCP value may be a value to indicatespecific video frames of the XR experience. In some implementations, theDSCP value is incremented for each successive video frame. At 1612, thedevice queues, for each video slice, the MSDUs for transmission to thesecond device. In some implementations, a queue is generated for eachvideo slice.

Process 1600 depicted in FIG. 16 is from the render device perspective.Process 1700 depicted in FIG. 17 may be similar to process 1600 but fromthe display device perspective.

FIG. 17 shows a flowchart illustrating an example process 1700 formanaging data for transmission according to some implementations. Thedevice performing the operations in process 1700 may be a displaydevice, and the second device may be a render device. At 1702, thedevice obtains, from the second device, one or more PPDUs associatedwith a video frame. Regarding the one or more PPDUs, the second devicerenders a plurality of video frames to be provided to the device (1704).The second device splits each video frame of the plurality of videoframes into a plurality of video slices (1706). For each video slice,the second device generates a plurality of PPDUs to include the videoslice (1708). Each PPDU includes one or more MSDUs associated with thevideo slice (1710). The video slice associated with the one or moreMSDUs may be identified by a port number and a DSCP value included ineach MSDU (1712). For each video slice, the second device queues theMSDUs for transmission to the device (1714). The queues may be MSDUqueues generated in software for each video slice, and each MSDU queuemay be identified by an IP address (such as the target IP address), portnumber, and DSCP value.

FIG. 18 shows a block diagram 1800 illustrating an example of generatingqueues for one or more video frames. The video 1802 includes videoframes Q and Q+1 (for integer Q equal to or greater than 1) rendered bythe render device. The render device may split each video frame intovideo slices. For example, video frame Q includes N video slices (forinteger N greater than or equal to 1), and video frame Q+1 includes Nvideo slices. The render device packages each video slice into aplurality of IP packets (such as R IP packets for each video slice forinteger R greater than or equal to 1), and the render device packageseach IP packet into an MSDU. As noted above, the render device mayidentify the MSDU for IP packet 1 of video slice 1 of video frame Q asthe first MSDU for video frame Q, and the render device may identify theMSDU for IP packet R of video slice N of video frame Q as the last MSDUfor video frame Q. The render device also may identify the MSDU for IPpacket 1 of video slice 1 of video frame Q+1 as the first MSDU for videoframe Q+1, and the render device may identify the MSDU for IP packet Rof video slice N of video frame Q+1 as the last MSDU for video frameQ+1. The render device creates queue 1 for the MSDUs of video slice 1 ofvideo frame Q, queue N for the MSDUs for video slice N of video frame Q,queue N+1 for the MSDUs for video slice 1 of video frame Q+1, queue 2*Nfor the MSDUs for video slice N of video frame Q+1, and so on. Whileeach video slice is depicted as being packaged into the same number ofIP packets, each video slice may be packaged into any suitable number ofIP packets.

Each queue may be an MSDU queue generated in software by the renderdevice (such as by the WCD) and stored in a memory of the render device.For example, the queues may be generated and stored in a memory 508 of aWCD 500 (FIG. 5 ), which may be implemented in the render device. AnMSDU queue may be identified and tracked by the WCD of the render devicebased on an IP address, a port number, and a DSCP value assigned to thevideo frame by the render device. All MSDUs in a queue are associatedwith the same IP address, port, and DSCP value.

The DSCP value may be based on the video frames being for an XRexperience. In this manner, the DSCP values may be application based. Insome implementations, the DSCP value also may be based on a type ofvideo frame. For example, a reference frame of the video (an i-frame)includes i-slices that may be associated with a different DSCP valuethan an intermediate frame of the video (a p-frame) including p-slices.The render device may use DSCP values previously reserved, which may bedefined at the render device and the display device as being associatedwith a priority of the specific video slices.

In some implementations, the render device assigns a traffic identifier(TID) for each video slice. The TID may be included in the MPDU MACheader of the PPDUs for the plurality of MSDUs associated with the videoslice. The TID is associated with an access category (AC) of the videoslice, and the AC may be associated with a priority of the video slice.In this manner, the render device may determine to transmit video sliceMSDUs over other data based on the TID indicating that the priority ofthe video slice is greater than the priority of the other data to betransmitted. In some implementations, the priority of the video slice isbased on whether the video slice is an i-slice or a p-slice. Forexample, an i-slice may be associated with a higher priority than ap-slice for transmission by the render device (which may be indicated bya different TID).

Based on the identifiers of the MSDU queues to specific video slices andframes, the render device may schedule the MSDUs for transmission in aplurality of PPDUs to the display device. For example, the render devicemay attempt to transmit the MSDUs from the MSDU queue of a first videoslice before transmitting the MSDUs from the MSDU queue of a next videoslice. The display device may fail to obtain one or more MSDUs from therender device (such as a result of interference on the wireless medium).For example, the display device may not provide a BA for a sent PPDU, orthe display device may provide a BA indicating which MPDUs (includingone or more MSDUs) were successfully obtained.

The video slices are associated with a latency requirement fordisplaying video frames at the video device. If one or more MSDUs arenot successfully delivered to the display device in an amount of time toallow the display device to display the video frame (such as notreceiving a BA indicating one or more MPDUs including the MSDUs within aset amount of time), the render device may move on to providing MSDUsfor a different video slice without completing delivery of the previousMSDUs. For example, referring back to FIG. 18 and assuming that videoframes Q and Q+1 are p-frames, the render device generates queues 1through N and attempts to deliver the MSDUs in those queues. As notedabove, rendering of the frames is at a defined interval. Render devicegoes on to generate queues N+1 through 2*N at time after generatingqueues 1 through N. The render device generating a new queue associatedwith the same video slice may indicate that the render device is not toattempt to deliver any more MSDUs from the previous queue. For example,video slice 1 of video frame Q and video frame Q+1 may refer to the samearea of a video frame (such as the same lines or columns between thevideo frames). If queue 1 is not empty (with additional MSDUs from queue1 to be delivered) by the time queue N+1 is generated, the render devicemay stop attempting to deliver the remaining MSDUs in queue 1 and beginproviding the MSDUs in queue N+1. As noted above, the video slice may beidentified by a port number, which may be used to determine that queueN+1 is associated with queue 1. The render device may flush queue 1(with the remaining MSDUs considered stale) so that the MSDUs are nolonger scheduled for transmission to the display device. In this manner,a first MSDU queue (generated for a first p-slice) may be flushed afterrendering a second p-slice associated with the first p-slice (such asthe same video slice of a successive p-frame) and before providing, tothe display device, a PPDU including one or more MSDUs associated withthe first p-slice (such as a PPDU including one or more MSDUs that arefailed to be delivered).

In some implementations, the render device may attempt to continue todeliver MSDUs associated with i-slices after a new corresponding i-sliceor a p-slice is generated. For example, an i-slice may be used as areference frame for the intermediate frames in a video generated by thedisplay device from the obtained PPDUs. Therefore, older i-slices maystill be of value to the display device since they may be used asreference for subsequent p-slices (such as to decode successivep-slices). The render device may not flush an MSDU queue associated witha previous i-slice upon rendering a new i-slice or p-slice associatedwith the previous i-slice. For example, the render device may continueto attempt to deliver MSDUs for the i-slice up until a threshold numberof successive i-slices, p-slices, or a combination thereof are rendered(such as until a second successive i-slice is rendered or a number ofp-slices up until the next i-slice is rendered). Referring back to FIG.18 and based on frames Q and Q+1 being i-frames (with one or morep-frames being between the i-frames (not shown)), the render device mayrender a first i-slice of frame Q, generate a first MSDU queueassociated with the first i-slice, render a second i-slice of frame Q+1associated with the first i-slice (such as the same video slice of thevideo frames), generate a second MSDU queue associated with the secondi-slice, and still provide a PPDU including one or more MSDUs with thefirst i-slice after generating the second MSDU queue.

As noted above, a PPDU may be attempted to be transmitted a thresholdnumber of times by the render device (such as five times). The PPDUincludes one or more MSDUs of an application file (such as a videoslice). If the PPDU fails to be delivered after a threshold number ofretries, the PPDU is not again attempted to be delivered to the displaydevice. In this manner, the display device does not obtain one or moreMSDUs of the video slice, and the display device may be unable togenerate the video slice from the MSDUs that are obtained since some ofthe MSDUs are missing. In some implementations, if a PPDU is failed tobe delivered after the threshold number of retries, the render device(such as the WCD) may flush the MSDU queue associated with the videoslice.

If a MSDU queue is flushed, the render device may generate a replacementvideo slice after flushing the MSDU queue. The replacement video slicemay be a new video slice based on a most recently obtained pose frame ora copy of the original video slice. After generating the replacementvideo slice, the render device may generate a replacement MSDU queueassociated with the replacement video slice (similar to as depicted inFIG. 18 for other video slices). With the replacement MSDU queuegenerated, the render device may attempt to transmit the MSDUs from thereplacement MSDU queue in one or more PPDUs to the display device.Generating a replacement video slice may be based on whether enough timeexists to provide the PPDUs including the replacement video slice to thedisplay device to display the video frame. For example, the renderdevice may determine not to generate a replacement video slice based onthe remainder of the TWT window being less than a threshold amount oftime. In this manner, the display device may display a video slice froma previous video frame or not display the video slice for the videoframe (which may include a black spot at the location of the videoslice).

In addition or alternative to an MSDU queue being flushed based on anumber of PPDU retries or arrival of a new video slice, the renderdevice may flush an MSDU queue based on an explicit command from theapplication layer. For example, a user of the render device may indicatethat a portion of the XR experience is to be reset or that the XRexperience is to be terminated. The scheduled MSDUs are no longer neededto be transmitted. The render device may generate the explicit commandto flush one or more MSDU queues at the application layer and providethe command to the WCD. The WCD may flush the one or more MSDU queuesbased on the command.

In some implementations, the render device indicates to the displaydevice that an MSDU queue is flushed. The indication may be included ina MAC header of a packet or a separate control element from the renderdevice to the display device. In this manner, the display device is madeaware of one or more missing MSDUs. The indication may indicate whichvideo slice is associated with the MSDU queue (such as providing the IPaddress, port number, and DSCP value used to identify the MSDU queue ina MAC header). Based on the indication, the display device may terminatestoring and processing MSDUs associated with the indicated video slice.For example, the WCD of the display device may include a reorder (REO)queue to obtain and store the MSDUs until all or a sufficient number ofMSDUs are obtained to reconstruct the application file (such as a videoslice). The REO queue may obtain one or more MSDUs from the renderdevice. If the display device obtains an indication that a transmitqueue associated with the one or more obtained MSDUs (such as an MSDUqueue that included the one or more MSDUs at the render device) isflushed, the obtained MSDUs may no longer be used in generating thevideo slice. In this manner, the display device may flush the REO queueafter obtaining the indication.

In some implementations, the display device may flush the REO queue ifall (or a sufficient number of) MSDUs associated with an applicationfile (such as a video slice) are not obtained. For example, the REOqueue may obtain a portion of MSDUs associated with a video slice, butthe REO queue may not obtain a remainder of the MSDUs associated withthe video slice before a REO timeout occurs. The display device mayflush the REO queue after not obtaining the remainder of the MSDUsbefore the REO timeout occurs. In one example, an REO timeout amount oftime may be a time from when obtaining the first MSDU of the applicationfile to the latest when the last MSDU of the application file is to beobtained. In another example, the REO timeout amount of time may be atime indicating when the video slices of an entire video frame are to beobtained. In some implementations, the REO timeout amount of time may bebased on the TWT window size. In some implementations, the REO timeoutamount of time is based on the AC of the video slice (such as based onthe TID for the video slice). An example REO timeout amount of time is10 ms, but any suitable amount of time may be used. The amount of timemay be counted from the beginning of the TWT window or any othersuitable starting point for determining if an REO timeout occurs. If thedisplay device counts up to the REO timeout amount of time beforeobtaining all MSDUs, the display device may flush the REO queue.

In some implementations, the display device may flush the REO queueperiodically. For example, the display device may flush the REO queuebetween TWT windows. In some implementations, the display device mayflush the REO queue based on an explicit command generated at theapplication layer. For example, the XR experience may be reset orterminated by a user of the display device or otherwise by the XRapplication layer. In this manner, the display device may generate acommand to flush the REO queue, as the obtained MSDUs are no longerneeded.

In contrast to requiring obtaining all MSDUs of an application file(such as a video slice) to generate the application file, use of FEC mayallow a display device to generate the application file after obtainingonly a portion of the MSDUs associated with the application file. Forexample, each MSDU may include a number of FEC bits at the end of thepayload. The FEC bits from the obtained MSDUs may be sufficient toconstruct the missing MSDUs. Since a portion of the MSDU payloads arereserved as FEC bits, the amount of payload provided in each MSDU isreduced, and the number of MSDUs for a video slice may increase.However, the display device may not need to obtain all MSDUs for thevideo slice to generate the video slice. In some implementations, FECmay be used or not used based on a link quality between the renderdevice and the display device (such as a reference signal receive power(RSRP) measurement, a reference signal receive quality (RSRQ)measurement, or a signal to noise ratio (SNR) measurement measured bythe display device). For example, FEC may be used by the display deviceand the render device if interference increases above a threshold (suchas indicated by SNR dropping below a threshold) or channel conditionsworsening below a threshold (such as indicated by RSRP or RSRQ droppingbelow a threshold). In some implementations, FEC may not be used if theframe rate, resolution, or other parameters of the video frames wouldnot permit use of FEC while still meeting latency requirements for thevideo frames. For example, FEC may not be used if the frame rate isgreater than a threshold frame rate, the video frame resolution isgreater than a threshold resolution, and so on. In some implementations,FEC may or may not be used based on one or more parameters of thedisplay device (such as channel size, MCS used for obtaining the PPDUs,and so on that may affect the throughput to the display device). Use ofFEC may be indicated by the display device to the render device in theone or more pose frames or by the render device to the display device ina MAC header of one or more PPDUs.

In some implementations of using FEC for each video slice, the displaydevice may indicate to the render device when enough MSDUs are obtainedto reconstruct the video slice. For example, the display device providesa BA to the render device to indicate that a PPDU was obtained from therender device. If the display device determines that the PPDU includedMSDUs sufficient to reconstruct the video slice, the display device mayindicate in the BA to the render device that a sufficient number ofMSDUs are obtained. For example, the aggregated control (A-Control)field of the MAC header of the BA may be configured to indicate that asufficient number of MSDUs for the video slice are obtained. The renderdevice may process the A-Control field to determine that no furtherPPDUs including MSDUs for the video slice are to be provided to thedisplay device (with the display device to generate the video slice fromthe already obtained MSDUs). The render device may flush the associatedMSDU queue after obtaining the indication.

Changes in the wireless medium and the XR experience may require changesat the render device or the display device in communicating data to theother device or performing one or more XR operations. For example, asthe wireless medium becomes more congested, the display device movesaway from the render device, or more interference exists on the wirelessmedium, the render device and the display device may adjust one or moreparameters to reduce the amount of information to be communicatedbetween the devices. Example parameters may be associated with the XRexperience (such as video frame rate, frame resolution, color palette,and so on that affects the size of the video or the wireless channel,channel size, MCS, use of FEC, TWT window size, and so on to affect thebit rate between devices and the success in delivering data between thedevices for the XR experience). The render device and the display devicemay be configured to provide feedback regarding data provided to theother device, and the device may be configured to adjust the XRexperience based on the feedback. For example, the render device maygenerate feedback based on transmitting PPDUs to the display device, andthe display device may generate feedback based on transmitting poseframes to the render device.

FIG. 19 shows a flowchart illustrating an example process 1900 forgenerating feedback according to some implementations. The deviceperforming the example process 1900 may be a render device, and thesecond device may be a display device. At 1902, the device attempts toprovide a plurality of PPDUs associated with one or more video frames ofan XR experience to a second device.

At 1904, the device measures one or more of a PPDU transmission latencyor a PPDU transmission drop associated with attempting to provide theplurality of PPDUs. For example, the render device may observe when a BAis not obtained for one or more PPDUs transmitted to the display device.In some implementations, the render device may determine that a PPDUtransmission drop occurs when a BA is not obtained for a transmittedPPDU. In some implementations, the render device may determine that aPPDU transmission drop occurs when the render device reaches a maximumnumber of retries for the PPDU and the render device is to no longerattempt to deliver the PPDU. The render device may count the totalnumber of PPDU transmission drops over time. The time may be over a TWTwindow, a set number of TWT windows, a set amount of time, or anothersuitable amount of time. In some implementations, the render device maydetermine a PPDU transmission drop rate, which may be the number of PPDUtransmission drops divided by the total number of PPDUs attempted to betransmitted to the display device.

The render device may determine a PPDU transmission latency based on theBAs obtained for delivered PPDUs to the display device. For example, therender device tracks a time when a PPDU is transmitted to the displaydevice (such as based on the WCD clock of the render device). The renderdevice also tracks a time when the BA associated with the PPDU isobtained from the display device (such as based on the WCD clock of therender device). The render device may determine the PPDU transmissionlatency for the PPDU to be the difference between the time the PPDU istransmitted and the time the BA is obtained. In some implementations,the render device may determine an average PPDU transmission latency,median PPDU transmission latency, or a distribution of PPDU transmissionlatency over a number of PPDU transmissions.

The one or more measurements (including the PPDU transmission latency orthe PPDU transmission drop) are associated with one or more parametersof the XR experience, and the one or more parameters of the XRexperience may be adjusted after the one or more measurements (1906). Insome implementations, the PPDU transmission latency and the PPDUtransmission drop may indicate if channel conditions are improving (suchas based on less interference, the display device moving closer to therender device, and so on) or channel conditions are degrading (such asbased on more interference, the display device moving away from therender device, and so on). The measurements also may indicate ifthroughput to the display device is increasing or decreasing. Based onthe measurements, the render device (and the display device) maydetermine if one or more parameters of the XR experience are to beadjusted to ensure the video (or other data of the XR experience) stillmeets the latency and packet loss requirements. For example, the renderdevice may reduce the channel size, increase the MCS, or use FEC if thePPDU transmission drop increases. As a result of reducing the channelsize, increasing the MCS, or using FEC, the throughput to the displaydevice decreases. If the decreased throughput is less than what isrequired for the current video, the render device may adjust one or morevideo parameters (such as decreasing the resolution, the frame rate, andso on). The measurements or the adjustments may be communicated to thedisplay device, and the display device may implement the one or moreadjustments.

Process 1900 depicted in FIG. 19 is from the render device perspectiveof generating feedback. Process 2000 depicted in FIG. 20 may be from thedisplay device perspective of generating feedback.

FIG. 20 shows a flowchart illustrating an example process 2000 forgenerating feedback according to some implementations. The deviceperforming the example process 2000 may be a display device, and thesecond device may be a render device. At 2002, the device attempts toprovide a plurality of pose data frames associated with one or morevideo frames of an XR experience to a second device. In someimplementations, the device also attempts to provide tracking frames tothe second device.

At 2004, the device measures one or more of a pose data frametransmission latency or a pose data frame transmission drop associatedwith attempting to provide the plurality of pose data frames. Forexample, the display device may observe when a BA is not obtained forone or more pose data frames transmitted to the render device. In someimplementations, the display device may determine that a pose data frametransmission drop occurs when a BA is not obtained for a transmittedpose data frame. In some implementations, the display device maydetermine that a pose data frame transmission drop occurs when thedisplay device reaches a maximum number of retries for the pose dataframe. The render device may count the total number of pose data frametransmission drops over time. The time may be over a TWT window, a setnumber of TWT windows, a set amount of time, or another suitable amountof time. In some implementations, the display device may determine apose data frame transmission drop rate, which may be the number of posedata frame transmission drops divided by the total number of pose dataframes attempted to be transmitted to the render device.

The display device may determine a pose data frame transmission latencybased on the BAs obtained for delivered pose data frames to the renderdevice. For example, the display device tracks a time when a pose dataframe is transmitted to the render device (such as based on the WCDclock of the display device). The display device also tracks a time whenthe BA associated with the pose data frame is obtained from the renderdevice (such as based on the WCD clock of the display device). Thedisplay device may determine the pose data frame transmission latencyfor the pose data frame to be the difference between the time the posedata frame is transmitted and the time the BA is obtained. In someimplementations, the display device may determine an average pose dataframe transmission latency, median pose data frame transmission latency,or a distribution of pose data frame transmission latency over a numberof pose data frame transmissions.

Similar to as described above with reference to FIG. 19 , the one ormore measurements (including the pose data frame transmission latency orthe pose data frame transmission drop) are associated with one or moreparameters of the XR experience, and the one or more parameters of theXR experience may be adjusted after the one or more measurements (2006).In some implementations, the pose data frame transmission latency andthe pose data frame transmission drop may indicate if channel conditionsare improving (such as based on less interference, the display devicemoving closer to the render device, and so on) or channel conditions aredegrading (such as based on more interference, the display device movingaway from the render device, and so on). Based on the measurements, thedisplay device (and the render device) may determine if one or moreparameters of the XR experience are to be adjusted to ensure the video(or other data of the XR experience) still meets the latency and packetloss requirements (such as described above). The measurements or theadjustments may be communicated to the render device, and the renderdevice may implement the one or more adjustments.

Referring back to the render device, the render device may obtain one ormore pose data frames from the display device (with each of the one ormore video frames associated with a pose data frame). The one or moremeasurements may include measurements based on the obtained pose dataframes. In some implementations, the render device may measure a posedata frame delivery latency associated with obtaining the one or morepose data frames. For example, with the start time of TWT windows knownand a pose data frame to be delivered at the beginning of a TWT window,the render frame may determine the difference between the start time ofthe TWT window and the time when the pose data frame is obtained (withthe times based on the WCD clock of the render device). In someimplementations, the time of the IMU measurement is included in the posedata frame (such as a time indicated by the application layer clock ofthe display device). Since the WCD clock of the render device and theapplication layer clock of the display device may be synchronized, therender device may determine a difference between the time of the IMUmeasurement and the time of obtaining the pose data frame. The renderdevice may determine an average pose data frame delivery latency, medianpose data frame delivery latency, or a distribution of the pose dataframe delivery latency over a number of pose data frame deliveries (suchas over a defined number of TWT windows or defined amount of time).

The one or more measurements by the render device may include afrequency of missing or delayed pose data frames. In someimplementations, the render device determines whether one or more posedata frames are missing or delayed. For example, the display device mayattempt to provide a pose data frame up to a timeout at the beginning ofeach TWT window. If the render device does not obtain the pose dataframe before the timeout, the render device may determine that the posedata frame is missing or delayed. The render device may count the numberof missing or delayed pose data frames over a determined number of TWTwindows. If the number increases as successive TWT windows occur, therender device determines that the frequency of missing or delayed posedata frames increases. If the number decreases as successive TWT windowsoccur, the render device determines that the frequency of missing ordelayed pose data frames decreases. In some implementations, thefrequency may be the number of pose data frames missing or delayeddivided by the determined number of TWT windows used in determining ifany pose data frames are missing or delayed.

Referring back to the display device, a REO queue of the display devicemay obtain one or more MSDUs from the render device. As noted above,each MSDU may be associated with an application file (such as a videoslice). The display device may flush the REO queue one or more times toremove one or more MSDUs from the REO queue. For example, the displaydevice may flush the REO queue based on obtaining an indication that atransmit queue at the render device was flushed (such as the MSDU queueof the render device associated with the MSDUs in the REO queue of thedisplay device). In another example, the display device may flush theREO queue periodically (such as between TWT windows). In anotherexample, the display device may flush the REO queue if a timeout occurs(such as all MSDUs or a sufficient number of MSDUs not being received ina defined amount of time to allow construction of the video slice fordisplay). In another example, the display device may flush the REO queueif MSDUs for a successive video slice are obtained before obtaining theremainder of MSDUs for the previous video slice. In another example, thedisplay device may flush the REO queue based on a command from theapplication layer of the display device. The one or more measurements atthe display device may include a REO flush time associated with flushingthe REO queue. In some implementations, the display device counts thenumber of times the REO queue is flushed over a defined amount of time(such as a TWT interval or a number of TWT intervals). The REO flushtime may be the average number of flushes per TWT interval, the totalnumber of flushes counted by the display device, or another suitableindication of the number of times the REO queue is flushed by thedisplay device.

The one or more measurements at the display device also may include avideo frame delivery latency. For example, for one or more video frames,the display device (such as at the REO queue) obtains a first MSDUassociated with a video frame. As noted above, the first MSDU mayinclude metadata to indicate that the MSDU is the first MSDU for thevideo frame. The display device also obtains a last MSDU associated withthe video frame, which may include meta data to indicate that the MSDUis the last MSDU for the video frame. In some implementations, the firstMSDU and the last MSDU may be identified by a DSCP value included in theMSDU. The display device may measure a video frame delivery latencyassociated with obtaining the first MSDU and the last MSDU for the videoframe. For example, the display device may determine a time when thefirst MSDU is obtained and a time when the last MSDU is obtained fromthe WCD clock of the display device. The display device may determine adifference in time between when the first MSDU is obtained and when thelast MSDU is obtained as the video frame delivery latency for the videoframe. In some implementations, the display device may determine anaverage delivery latency, a median delivery latency, or a distributionof delivery latencies for a number of video frame delivery latencies.

The pose data frame or video frame delivery latencies, the frequency ofdropped or missing pose data frames, or the flush times increasing mayindicate that channel conditions are worsening or that throughputbetween the devices is somehow being restricted. Conversely, pose dataframe or video frame delivery latencies, the frequency of dropped ormissing pose data frames, or the flush times decreasing may indicatethat channel conditions are improving or that throughput between thedevices is increasing.

The one or more measurements at the display device also may include oneor more of a jitter buffer underflow or overflow or a missing packetassociated with a video frame to be displayed. As noted above, thedisplay device may perform dejittering in processing the video framesbefore display. Dejittering uses a jitter buffer of video frameinformation to allow smoothing of the display of video frames. If datain the buffer drops below a lower threshold, the display device maydetermine a jitter buffer underflow, and if the data in the buffer risesabove an upper threshold, the display device may determine a jitterbuffer overflow. Underflow (which results from a lack of data) andoverflow (which results in too much data such that some data may beleaked from the buffer) may negatively impact dejittering by the displaydevice. In some implementations, the display device may count the totalnumber of overflows or underflows, and average buffer usage, or othermetric over a defined amount of time associated with the jitter buffer.

A missing packet associated with a video frame to be displayed mayinclude a missing video slice. The display device may display one ormore video frames missing one or more video slices. In someimplementations, the one or more measurements includes a count of thenumber of video frames displayed missing one or more video slices, thenumber of video slices missing, or another suitable metric of missingpackets over a defined amount of time.

For the render device or the display device, the one or moremeasurements may include a link quality measurement of a link qualitybetween the render device and the display device. For example, thedisplay device or the render device may measure an RSRP, RSRQ, SNR, orother metric indicating a link quality between the devices. Changes in alink quality metric may indicate worsening channel conditions orimproving channel conditions.

Based on one or more heuristics for the one or more measurements (suchone or more thresholds for the measurements) or based on any suitablemachine learning model for the one or more measurements, the renderdevice or the display device may adjust one or more parameters of the XRexperience to ensure latency requirements are met for the XR experience.The one or more parameters of the XR experience may include one or morewireless communication parameters between the render device and thedisplay device. Adjusting one or more wireless communication parametersmay include one or more of:

-   -   adjusting a duty cycle of TWT windows for a TWT power save mode.        The duty cycle may be the length of the TWT window compared to        the amount of time outside of the TWT window during a TWT window        interval;    -   enabling or disabling the TWT power save mode;    -   changing a wireless operating channel over which the render        device and the display device communicate;    -   adjusting the wireless operating channel size (such as        increasing or decreasing the channel size between 20 MHz, 40        MHz, 80 MHz, 80+80 MHz, and 160 MHz);    -   adjusting a MCS;    -   enabling or disabling FEC for providing the PPDUs from the        render device to the display device; or    -   adjusting the FEC (such as the code rate of the FEC, which may        be associated with the number of bits in the payload to be used        for FEC).

In some implementations, the one or more parameters of the XR experiencemay include one or more video parameters. Adjusting one or more videoparameters may include adjusting one or more of a video frame rate, avideo resolution (such as a frame resolution), a target encode data rate(also referred to as an encoding bit rate), or a video codec. In someimplementations, the render device may adjust a render rate of the videoframes based on the video frame rate, the video resolution, the encodingbit rate, or the video codec. In some implementations, the displaydevice may adjust a display rate of the video frames based on the videoframe rate. Each of a video resolution, an encode data rate, and a videocodec are a tradeoff between video quality and file size. For example,selection of a video codec is based on balancing compression of thevideo with video quality. The render device may adjust the videoresolution, the target encode data rate, or the video codec (such asswitching between available codecs for encoding the video) to balancevideo quality with file size and latency requirements.

In some implementations, adjusting the one or more parameters mayinclude adjusting a functional split of computing tasks between thedisplay device and the render device or a relay STA to the displaydevice and another device communicably coupled to the relay STA. Forexample, based on the one or more measurements, the display device maydetermine that some rendering should be performed at the display device(such as when the link to the render device is determined to be bad(such as a link quality being less than a threshold or being indicatedas bad). For example, one or more p-frames may be rendered at thedisplay device. In this manner, fewer PPDUs are to be transmitted fromthe render device to the display device. Similarly, if an AP or anotherSTA is to render the video frames, and the rendered frames are relayedthrough a relay STA to the display device, the relay STA may determinethat rendering one or more video frames is to be performed at the relaySTA instead of the other STA or AP based on the one or moremeasurements.

The display device or the render device may indicate the one or moremeasurements or the adjustments made to the one or more parameters ofthe XR experience to the other device. In some implementations, a devicemay provide an indication of the one or more measurements to the otherdevice in an A-Control field of a header of one or more packets providedto the other device. The one or more packets may be included in an RTSframe or a CTS frame (if RTS/CTS is enabled, such as for asynchronouschannel access), a data frame (such as the one or more PPDUs from therender device to the display device or the one or more pose data framesfrom the display device to the render device), or a BA frame (such as aBA to the render device and associated with obtaining a PPDU or a BA tothe display device and associated with obtaining a pose data frame). Anexample A-Control field may be a variant of the HT control field (HEA-Control field) as defined in the IEEE 802.11ax standard. In anexample, the A-Control field may be included in a frame control field ofa MAC header of an RTS frame or a CTS frame. In another example, theA-Control field may be included in the non-legacy fields 212 of theexample PDU in FIG. 2A. In another example, the A-Control field may beincluded in the frame control field of the MAC header 412 in the MPDUsubframe 406 in FIG. 4 . In another example, the A-Control field may beincluded in the frame control field of the MAC header of the BA frame.

FIG. 21 shows a block diagram of an example control field 2100. Thecontrol field 2100 may be a simplified version of the A-Control fieldincluded in one or more frames. The actual A-Control field may includeadditional subfields not shown (such as an end of header (EOH) and soon). The control field includes a control identifier (ID) subfield 2102and a control information subfield 2104. The control ID in the subfield2102 indicates what type of control information is included in subfield2104. For example, based on HE control fields, the subfield 2102 mayinclude different numbers as control IDs for different controlinformation. A control ID of 0 may indicate that subfield 2104 includesan ACK, a control ID of 2 may indicate that subfield 2104 includes a BA,and so on. The IEEE 802.11ax standard reserves some control IDs fromuse.

In some implementations, the A-Control field (such as subfield 2102)includes a reserved control ID to indicate the one or more measurementsfrom the display device or the render device are included in theA-Control field (such as subfield 2104 being used to include the one ormore measurements). The reserved control ID may be defined at both therender device and the display device to allow encoding and decoding theA-Control field. In some implementations, different control IDs may beused for different types of measurements.

In some implementations, the A-Control field (such as subfield 2102)includes a reserved control ID to indicate the one or more adjustedparameters are included in the A-Control field (such as subfield 2104being used to include an indication of the one or more adjustedparameters). The reserved control ID may be defined at both the renderdevice and the display device to allow encoding and decoding theA-Control field. In some implementations, different control IDs may beused for different types of adjustments.

In indicating the one or more measurements, the A-Control field mayinclude an indication of the link quality (which may be measured by therender device or the display device, as noted above). In someimplementations, the link quality may be indicated as good or bad in abinary manner. For example, if a device measures an SNR, the device maycompare the SNR to a threshold. If the SNR is less than the threshold,the link quality may be considered bad. If the SNR is greater than thethreshold, the link quality may be considered good. The A-Control field(such as the subfield 2104) may include a bit reserved to indicate thelink quality (such as 0 for bad and 1 for good). The remaining bits ofthe subfield may be used to indicate the one or more measurements or theadjustments to the one or more parameters based on the one or moremeasurements.

In this manner, the display device and the render device may providefeedback to each other and adjust the XR experience as necessary.Providing feedback may be performed for both asynchronous channel accessand synchronous channel access. While the feedback and adjustments aredescribed with reference to an XR experience. The operations formeasuring and providing feedback described above may be applied to othertypes of data and other types of applications.

As depicted in FIG. 1B, a device 154 may support concurrent links with afirst device 152 (such as a display device) and a second device 158(such as an AP of the BSS or another STA in a mesh network). In someimplementations, link 156 may be in the 5 GHz or 6 GHz frequencyspectrum, and link 160 may be in the 5 GHz or 6 GHz frequency spectrum.The device 154 is configured to support concurrent links while stillsupporting the XR experience (such as prioritizing XR traffic andotherwise managing XR operations to meet latency and other requirementsfor the XR experience).

The concurrent links may be managed using TWT sessions (such asdescribed above, with the AP or other STA communicating outside of theTWT window for the display device and the render device). For legacydevices that do not support TWT, concurrent links may be supported usingmulti-link operation (MLO) techniques (such as defined in the IEEE802.11 standards).

FIG. 22 shows a flowchart illustrating an example process 2200 forsupporting concurrent wireless links with multiple devices. The exampleprocess 2200 may be performed by a WCD (such as WCD included in a renderdevice or another suitable device supporting concurrent wireless linkswith a first device and a second device). In some implementations, thesecond device is a display device. In some implementations, the firstdevice may be an AP (in a BSS) or another STA (in a mesh network). Theexample process 2200 is described below as being performed by a renderdevice or a WCD of a render device for clarity purposes, but the exampleprocess 2200 may be performed by any suitable device.

At 2202, the render device (such as the WCD of the render device)communicates with a first device over a first wireless link. Forexample, the render device communicates with an AP or another STA.

At 2204, the render device communicates with a second device over asecond wireless link. For example, the render device may communicatewith a display device over a first wireless link configured between therender device and the display device for an XR experience. The WCDcommunicates concurrently with the first device and the second deviceusing one of MLO techniques or a TWT mode (2206). TWT mode (alsoreferred to as TWT) techniques may include operations described abovewith reference to synchronous channel access, application based datamanagement, and generating feedback. MLO techniques may be similar tosome TWT mode techniques, but may be supported by legacy devices that donot support TWT.

The WCD is configured to give preference to communications on the secondwireless link versus communications on the first wireless link (2208).For example, the second wireless link may be between the render deviceand a display device for an XR experience. XR data to be transmittedbetween the render device and the display device (such as PPDUs, posedata frames, and tracking frames) are associated with a latencyrequirement or packet loss requirement associated with the XRexperience. In this manner, communications between the render device andthe display device may be of more importance than communications betweenthe render device and the other device (such as an AP or render deviceattempting to transmit best effort classified traffic to the otherdevice). Example operations for the WCD to give preference tocommunications on the second wireless link versus communication on thefirst wireless link are described in more detail below.

Concurrently communicating with the first device (such as an AP) and thesecond device (such as a display device) may include:

-   -   the WCD is to transmit to the second device during reception of        one or more packets from the first device (such as to transmit        to the display device when receiving from the AP);    -   the WCD is to obtain one or more packets from the second device        during reception of one or more packets from the first device        (such as to receive from the display device when receiving from        the AP);    -   the WCD is to transmit to the second device during transmission        to the first device (such as to transmit to the display device        when transmitting to the AP); or    -   the WCD is to obtain one or more packets from the second device        during transmission to the first device (such as to receive from        the display device when transmitting to the AP).

Typical MLO techniques are defined to prevent transmission on a linkwhen reception is on-going on another link. For example, allowingtransmission on a wireless link may be based on a clear channelassessment (CCA) of the wireless medium (which includes both wirelesslinks). If the CCA indicates that the wireless medium is occupied (suchas when the WCD is receiving from the first device), the WCD preventstransmissions. In this manner, if a WCD is configured for typical MLO,the WCD prevents transmission to the second device over the secondwireless link when receiving from the first device over the firstwireless link, and the WCD prevents transmission to the first deviceover the first wireless link when receiving from the second device overthe second wireless link. Typical MLO techniques may preventcommunications between the render device and the display device thatwould negatively impact the XR experience (such as not meeting certainlatency requirements). If MLO techniques are to be used by a renderdevice for concurrent link support, the WCD of the render device may beconfigured to enhance the MLO techniques (and other MAC operations) toprovide preferential treatment to communications with the displaydevice. For example, the WCD may allow transmission to the displaydevice while receiving from another device (such as an AP or STA). Insome implementations, the WCD may be configured to ignore a CCA when theWCD is to transmit to the display device. Example adjustments to the MLOtechniques for the different example concurrent communications aredescribed below.

One example concurrent communication includes the WCD receiving one ormore packets from the first device and the WCD transmitting to thesecond device. For example, the render device may be in the process ofobtaining one or more packets from an AP or STA. While obtaining the oneor more packets, the render device may determine that the render deviceis to transmit to the display device (such as transmitting one or morePPDUs associated with one or more video frames). The WCD may transmit tothe second device before completion of reception of the one or morepackets from the first device. The examples described herein refer tothe WCD or device managing the concurrent links as a render device, thesecond device as a display device, and a first device as an APexclusively for simplicity and clarity in describing aspects of thepresent disclosure. To note, the examples are not limited to a renderdevice, display device, AP, or any other specific device.

A render device typically would provide a BA to the AP after obtainingthe one or more packets over the first wireless link. If transmissionover the second wireless link to the display device is still ongoingwhen the render device is to provide the BA to the AP, a CCA wouldindicate that the wireless medium is busy, and the render device wouldprevent providing the BA to the AP. The render device obtains a BA fromthe display device after transmitting to the display device (such asobtaining a BA from a display device after delivering a PPDU to thedisplay device). Based on typical MLO, if the end of reception from theAP coincides with the end of transmission to the display device, the CCAat the render device would not cause the render device to preventproviding the BA to the AP. However, the BA may be provided to the APnear the same time a BA from the display device is to be obtained. Ifthe BA to the AP and the BA from the display device overlap on thewireless medium, the render device may not successfully obtain the BAfrom the display device. Not obtaining the BA causes the render deviceto retry transmitting to the display device (which increases the latencyin delivering data to the display device).

In some implementations of enhancing MLO, the render device (such as theWCD) prevents providing a BA to the AP to acknowledge reception of theone or more packets. In this manner, the BA obtained from the displaydevice is not interfered with by a BA to the AP. For example, the renderdevice may determine if the WCD is in a transmit mode for the secondwireless link. If the WCD is in a transmit mode for the second wirelesslink, the render device may prevent providing a BA over the firstwireless link. With the render device to prevent transmitting a BA tothe AP for the one or more packets, communication of the one or morepackets over the first wireless link may be considered to have failed.With the AP not obtaining a BA from the render device, the AP later mayretry to transmit the one or more packets to the render device(increasing the latency of delivering the one or more packets from theAP). Increasing the latency on the first wireless link over increasingthe latency on the second wireless link may be acceptable based on thelatency requirements between the render device and the display device(such as for an XR experience).

Another example concurrent communication includes the render devicereceiving one or more packets from the AP and the render devicereceiving one or more packets from the display device. For example, therender device may be receiving from the AP over the first wireless linkwhen pose data frames, tracking frames, or other packets are provided bythe display device over the second wireless link. The render deviceobtains one or more packets from the display device during reception ofone or more packets from the AP. The render device provides a BA to thedisplay device after obtaining the one or more packets from the displaydevice. In some implementations, to prevent interference with receivinginformation from the display device, the render device may preventproviding a BA to the AP to acknowledge reception of the one or morepackets from the AP. For example, transmitting on a first one or moreantennas over the first wireless link may cause a local interference ona second one or more antennas receiving over the second wireless link.Preventing transmission of the BA to the AP prevents generating thelocal interference in receiving from the display device.

Another example concurrent communication includes the render devicetransmitting to the AP and the render device transmitting to the displaydevice. For example, the render device may be transmitting to the APover the first wireless link when the render device determines totransmit one or more PPDUs to the display device over the secondwireless link. If data arrives at the WCD for transmission (such as oneor more MSDUs to be included in one or more PPDUs transmitted to thedisplay device) at the same time as an ongoing transmission to the AP,typical MLO techniques would require the render device to determine aCCA (which would indicate that the wireless medium is busy). In thismanner, the render device would delay transmitting to the display device(increasing the latency over the second wireless link). One or moreenhancements to the MLO techniques may be applied to attempt to avoid orreduce such delay in transmission to the display device.

In one example enhancement to the MLO techniques, the render devicesynchronizes transmissions to the display device with transmissions tothe AP. For example, the start of transmissions to the AP and to thedisplay device may be synchronized. Synchronizing the start oftransmissions may be based on a transmission schedule or knowntransmission period from the render device to the display device. Forexample, rendering video frames may be at regular intervals, with theMSDUs available for transmission at the regular intervals (which mayvary within a tolerance amount of time associated with any latencies,such as UL latencies or rendering latencies). Before the render devicebegins transmission to the AP, the render device may determine if thecurrent time is within a threshold amount of time that MSDUs are to betransmitted to the display device. If within the threshold amount oftime, the render device may delay transmission to the AP to synchronizethe transmissions to the AP and to the display device. In someimplementations, if a BO is used for obtaining control of the wirelessmedium or otherwise to transmit to the display device, the render devicemay reduce the BO associated with the second wireless link tosynchronize transmissions over the first wireless link and over thesecond wireless link.

Transmissions to the display device may be shorter than transmissions tothe AP. If the transmission to the display device ends first, a BA maybe transmitted by the display device while the render device still istransmitting to the AP (which may affect the render device receiving theBA). In some implementations of synchronizing transmissions, the renderdevice may pad the transmission to the display device to cause an end oftransmission to the AP to be synchronized with an end of transmission tothe display device. Example padding may include zero padding or addingany suitable tail to the transmission to the display device tosynchronize the ends of transmission. The render device may determinethe amount of padding to be applied based on the amount of datascheduled to be transmitted to the AP, the amount of data scheduled tobe transmitted to the display device, and the measured throughputs overthe first wireless link and over the second wireless link. In someimplementations, a reduced BO associated with the second wireless linkmay compensate for the padding so that the latency over the secondwireless link is not impacted.

In another example enhancement to the MLO techniques, the render devicemay prevent transmission to the AP outside of one or more time divisionmultiplexing (TDM) windows. A TWT session may be conceptualized as aform of time division multiplexing of the wireless medium. For example,communications between a render device and a display device may beduring the TWT windows, and communications between the render device andanother device (such as an AP or a STA) may be outside of the TWTwindows. As noted above, some legacy devices do not support TWT. Awireless system including one or more legacy devices may be configuredto share the wireless medium using TDM windows. For example, an AP of aBSS including the render device and the display device may configure oneor more TDM windows to communicate with the render device. Configuringthe TDM windows may include configuring a window length, periodicity,and other parameters for the TDM window. In this manner, transmissionsfrom the render device to the AP are during the one or more TDM windows,and transmissions from the render device to the display device (such asPPDUs transmitted to the display device) are outside of the one or moreTDM windows. With TDM windows defined, a maximum delay to transmit tothe display device (outside of the TDM windows) is based on a remaininglength of a current TDM window.

In another example enhancement to the MLO techniques, the render devicemay reduce a maximum PPDU duration or a burst duration. The PPDUduration may be based on the PPDU size and throughput. If the maximumPPDU duration is reduced, the maximum amount of time to transmit a PPDUmay be reduced. The burst duration may be the amount of time the renderdevice is to transmit PPDUs to the display device. Shortening the burstduration shortens the amount of time that the wireless medium is to bereserved exclusively for transmissions to the display device. Shorteningthe amount of time that is to be reserved for transmitting a PPDU or atransmission duration to the display device allows the render device tomore quickly schedule a new PPDU transmission or a new TXOP associatedwith the burst duration. In this manner, the potential delay fortransmission to the display device may be reduced by reducing themaximum PPDU duration or the burst duration.

In another example enhancement to the MLO techniques, the render devicemay interrupt transmission to the AP so that the render device no longeris transmitting to the AP. As noted above, one or more MSDUs are readyto be transmitted by the render device to the display device while therender device is transmitting to the AP. The packets to be transmittedto the AP are included in a transmit buffer of the WCD of the renderdevice. To interrupt transmission to the AP, the render device may flushthe packets from the transmit buffer associated with the transmission tothe AP. With the transmit buffer empty, the transmission to the AP ends.In this manner, when the render device performs CCA for transmittingover the second wireless link, the CCA may indicate that the wirelessmedium is free for the render device to transmit to the display deviceover the second wireless link.

In another example enhancement to the MLO techniques, the render devicemay use CTS to self (CTS-to-Self) frames to extend reservation of awireless medium for transmitting to the display device. For example,when the render device transmits to the AP, the wireless medium isreserved for the render device (such as described above regarding theCTS/RTS mechanism between the render device and the display device).When the reservation ends, other devices may contend for the wirelessmedium or be scheduled to transmit over the wireless medium, and therender device may wait for the other devices to finish occupying thewireless medium. In some implementations, when the render device hasMSDUs ready for transmission to the display device, the render devicedetermines an amount of time to transmit the MSDUs (such as based on theamount of data in one or more MSDU queues associated with the secondwireless link). The render device also determines the remaining amountof time to transmit to the AP (such as based on the amount of dataremaining in the transmit buffer associated with the first wirelesslink). The render device may determine if any time from the reservationwill be remaining based on the remaining amount of time to transmit tothe AP, and the render device may determine an additional amount of timeto the reservation to allow transmitting the MSDUs to the display deviceduring the same reservation. In this manner, transmissions to the AP andtransmissions to the display device may occur during the samereservation (which reduces the delay versus requiring a new reservationfor transmitting to the display device). To extend the reservation ofthe wireless medium, the render device may broadcast a CTS-to-Selfframe. The CTS-to-Self frame may indicate to pad the time period thatthe wireless medium is reserved (such as a value to be added to thecurrent NAV of each device obtaining the CTS-to-Self frame). As notedabove, the padded time period is of sufficient length to include thetransmission to the AP and the transmission to the display device.

Another example concurrent communication includes the render devicetransmitting to the AP and the render device obtaining one or morepackets from the display device. For example, the render device may betransmitting to the AP over the first wireless link when the displaydevice transmits a pose data frame or tracking frame over the secondwireless link. If the render device is transmitting over the secondwireless link when packets are being transmitted by the display deviceto the render device, the render device may be unable to obtain thepackets from the display device. With the render device not obtainingthe packets from the display device, the render device does not providea BA to the display device, and the display device retransmits thepackets to the render device. Based on typical MLO techniques, thedisplay device may continue attempting to transmit the packets until thepackets are successfully delivered or a maximum number of retriesoccurs. As the display device continues retries, the transmissionparameters may be adjusted to attempt to increase the likelihood thatthe packets are delivered. For example, the display device increases theMCS, uses FEC, and lowers the transmission rate. The transmission ratemay continue to be lowered, and the lowered transmission rate wouldcause issues in meeting latency requirements for the XR experience.

The MLO techniques may be enhanced to avoid or reduce the transmissiondelay or prevent adjusting the transmission parameters at the displaydevice that may negatively impact a communication latency between thedisplay device and the render device. In one example enhancement to theMLO techniques, one or more TDM windows may be used to prevent packetsbeing transmitted by the display device during the TDM windows. The TDMwindows reserve the wireless medium for communications between therender device and the AP (such as described above). For example,transmission to the AP is during the one or more TDM windows, andreception from the display device is outside of the one or more TDMwindows. In this manner, the render device is prevented from obtainingthe one or more packets from the display device during the one or moreTDM windows.

In another example enhancement to the MLO techniques, the render devicemay reduce the maximum PPDU duration or the burst duration. As notedabove, reducing the maximum PPDU duration or the burst duration reducesthe amount of time the render device transmits to the AP. In thismanner, the amount of time that the display device is to retrytransmitting to the render device is reduced (which reduces the delayassociated with the display device transmitting to the render device).

In another example enhancement to the MLO techniques, the render devicemay indicate to the display device that the wireless medium is to bebusy for an amount of time associated with transmitting to the AP. Forexample, the render device may provide a frame to the display deviceindicating a NAV value to reserve the wireless medium for the durationof transmitting to the AP. In some implementations, the NAV value may beincluded in a PPDU transmitted from the render device to the displaydevice. In this manner, the display device sets its NAV to the indicatedNAV value to prevent transmitting to the render device during theindicated duration.

While use of TDM windows and other MLO techniques are described withreference to legacy devices that do not support TWT, the describedtechniques may be implemented in any device (including devicessupporting TWT). In addition or to the alternative, the techniques maybe applied outside of MLO, and the techniques are not limited to aspecific concurrent link support implementation.

In addition or alternative to using MLO techniques for supportingconcurrent links, a render device may use TWT to support concurrentlinks. In some implementations, the render device (or the displaydevice) may configure a first TWT session with the display device forcommunications with the display device over the second wireless link,and the render device may configure a second TWT session with the AP forcommunications with the AP over the first wireless link. The first TWTsession includes a first plurality of TWT windows, and the firstplurality of TWT windows is associated with XR activity at the renderdevice (such as obtaining one or more pose data frames or trackingframes from the display device, rendering one or more video frames, andproviding the one or more video frames via one or more PPDUs to thedisplay device). The second TWT session includes a second plurality ofTWT windows interspersed between the first plurality of TWT windows andnot overlapping with the first plurality of TWT windows. For example,the TWT windows may alternate (such as a TWT window from the firstplurality, a TWT window from the second plurality, a TWT window fromfirst plurality, and so on). In this manner, the render devicecommunicates with the display device during the first plurality of TWTwindows, and the render device communicates with the AP during thesecond plurality of TWT windows.

The first TWT session is configured by the render device or the displaydevice to meet any latency or packet loss requirements associated withan XR experience. After the first TWT session is established, the renderdevice may initiate configuration of the second TWT session with the AP,with the second TWT session to include TWT windows outside of the TWTwindows of the first TWT session. With the second TWT session configuredbased on the first TWT session, the first TWT session may be consideredthe primary TWT session, and the second TWT session may be considered asecondary TWT session. As noted above, the AP may be an IEEE 802.11axenabled AP to support TWT (including the second TWT session with therender device).

As noted above regarding feedback and adjustments, the first TWT sessionmay be adjusted (such as adjusting TWT window lengths, interval, and soon). The render device or the display device may adjust the first TWTsession without reference to the second TWT session. In this manner, thefirst TWT session may be adjusted that would cause conflict with thesecond TWT session (such as overlapping TWT windows from the two TWTsessions). After the first TWT session is adjusted, the render devicemay initiate an adjustment of the second TWT session with the AP toavoid overlapping TWT windows. In this manner, the second TWT session isadjusted based on adjustments to the first TWT session.

In configuring the TWT sessions or adjusting the TWT sessions, therender device may act as a STA to the AP and may act as an SAP to thedisplay device. In this manner, the render device may be conceptualizedas having a STA-associated MAC and an SAP-associated MAC supported bythe WCD of the render device. The SAP-associated MAC is used inconfiguring and adjusting the first TWT session with the display device,and the STA-associated MAC is used in configuring and adjusting thesecond TWT session with the AP. With the first TWT session being theprimary TWT session, after configuring or adjusting the first TWTsession, information or changes regarding the first TWT session arecommunicated from the SAP-associated MAC to the STA-associated MAC. Inresponse to obtaining the information or changes to the first TWTsession at the STA-associated MAC, the render device may negotiate withthe AP to configure or adjust the second TWT session. In someimplementations, the AP may have its own TWT requirements (such as basedon supporting other devices in the BSS). The render device may configurethe second TWT session with the AP to ensure the AP's requirements aremet. The render device also may configure the first TWT session beforeconfiguring the second TWT session to support the AP's requirementswhile also meeting any latency and packet loss requirements associatedwith the XR experience.

In some implementations, the TWT windows of the second TWT session arescheduled to take into account a S2 W duration of the WCD for theSTA-associated MAC. For example, the TWT windows of the second TWTsession are scheduled so that the S2 W duration does not overlap with XRactivity (such as receiving from and transmitting to the display deviceas described above).

FIG. 23 shows a sequence diagram 2300 illustrating example timings of XRactivity and wireless activity with an AP (referred to as wirelessactivity). A first XR activity 2302 (such as from receiving a pose dataframe to providing a current video frame over the second wireless link)has a start time 2304, and a second XR activity 2306 (such as fromreceiving a next pose data frame to providing a next video frame overthe second wireless link) has a start time 2308. In someimplementations, the XR activity 2302 corresponds to a first TWT windowof a first TWT session, and the XR activity 2306 corresponds to a secondTWT window of the first TWT session. The XR activity is periodic (suchas based on the display rate or render rate of the video), and a periodduration 2310 of the periodic activity is a difference between starttimes 2308 and 2304. Wireless activity 2312 (associated withcommunications between the render device and the AP over the firstwireless link) is to be scheduled outside of the XR activities 2302 and2306 (such as between TWT windows corresponding to the XR activities2302 and 2306). The wireless activity 2312 has a start time 2314 and anend time 2316 to be scheduled. The wireless activity 2312 may correspondto a first TWT window of a second TWT session. The start time 2314 maybe more than a buffer 2318 after the XR activity 2302. For example, asnoted above, one or more PPDUs may be transmitted to the display deviceafter a TWT window or when PPDUs are delivered to the display device mayvary depending on channel conditions or other latencies. In this manner,the duration of the XR activity 2302 may vary. The buffer 2318 may befor a defined amount of time to account for variations in the durationof the XR activities (including XR activity 2302). As depicted, starttime 2314 is after buffer 2318.

Start time 2314 also may be scheduled to account for a S2W duration atthe render device to ensure reception and transmission with the displaydevice (or the AP) is not affected by one or more WCD components comingout of a low power mode. Assuming a generic XR activity start time is x,the period duration is P_(R), the XR activity duration (such as thelength of the XR activity 2302) is A_(R), the buffer duration is z, ageneric wireless activity start time is y, a TWT wake interval (such asthe interval of the TWT windows during which time the WCD is to remainin an active mode) is Pw, and the duration of the wireless activity (thedifference between end time 2316 and start time 2314) is Aw, thewireless activity is scheduled not to overlap with the XR activity forany cycle of the wireless activity (nw, assuming the wireless activityis cyclic) and any cycle of the XR activity (n_(R)), which ismathematically depicted in equations (1)-(3) below:

$\begin{matrix}{P_{W} = \frac{\left( {x + z - y} \right) + {n_{R}P_{R}} + A_{R}}{n_{W}}} & (1)\end{matrix}$ $\begin{matrix}{A_{W} \leq {P_{R} - A_{R}}} & (2)\end{matrix}$ $\begin{matrix}{P_{W} \geq {A_{R} + A_{W}}} & (3)\end{matrix}$

In this manner, start time 2304 may be x+n_(R)P_(R) for any cycle of XRactivity, start time 2308 may be x+(n_(R)+1)P_(R), the end of XRactivity 2302 may be x+n_(R)P_(R)+A_(R), and the end of XR activity 2306may be x+(n_(R)+1)P_(R)+A_(R). Start time 2314 may be y+nwPw, and endtime 2316 may be y+nwPw+Aw. Pw may be configured to be one or moremultiples of P_(R). If TWT is used for communications between the renderdevice and the display device, P_(R) is a constant value across allcycles of XR activity (assuming no adjustments are made to the XRactivity, such as based on feedback).

The render device may use TDM windows that are not defined in a TWTsession. For example, as noted above, one or more MLO techniques mayinclude the use of TDM windows. In some implementations, P_(R) may varybetween different cycles of XR activity (such as resulting from delaysin transmission or reception resulting from concurrent communications).The render device may schedule wireless activity for such TDM windowssimilar to as above with reference to equations (1)-(3), but regarding avarying P_(R). For example, the render device may attempt to determine acommon multiple of possible P_(R) that may occur based on possibledelays or variations in the XR activity. In this manner, the wirelessactivity 2312 is ensured not to overlap with any of the XR activities(including XR activities 2302 and 2306).

Referring back to use of TWT for concurrent link support, theapplication layer clock and the WCD clock of a device may have differentfidelities. For example, the application layer clock may be able toindicate a value with more fidelity (also referred to as granularity)than the WCD clock. The difference in fidelity also may be caused byP_(R) being indicated in a different manner than Pw. For example, P_(R)may be indicated as a time every number of cycles (such as 50 ms per 3cycles) of XR activity). However, Pw (which is to equal P_(R)) may bedetermined per cycle of wireless activity. For example, if P_(R) is 50ms per 3 cycles (which would be 50/3 ms per cycle) and Pw is to equalP_(R), the render device may approximate Pw based on a fidelity of theWCD clock (such as 1 ρs being the minimum unit of time). In thisexample, Pw would be restricted to being indicated as 16.666 ms or16.667 ms, which is an approximation of 50/3 ms. As a result of the WCDclock fidelity limiting the indication of Pw, the period duration ofwireless activity 2312 differs from the period duration 2310 of XRactivity (such as up to 1 ρs per cycle in the example). In the exampleof Pw being determined to be 16.666 ms and P_(R) being 50/3 ms, thewireless activity shifts 3.88 ms every 194 seconds with reference to theXR activity. In some implementations, the buffer is configured toaccount for an amount of drift in the wireless activity over timeresulting from the approximation error in measuring Pw. If the buffer2318 is 3.88 ms, the wireless activity may begin to overlap the previousXR activity after 194 seconds.

In some implementations, drift between XR activity and wireless activitymay occur based on a difference in resonance frequencies associated withan application layer clock and a WCD clock of a device. As noted above,different crystals may be used for the application layer clock and theWCD clock. The crystals may have different resonance frequencies uponwhich the clocks are based. In addition, the crystals may be affecteddifferently by environmental conditions (such as temperature ormoisture) that varies the resonance frequencies. The device may assumethat the resonance frequencies are the same, but the wireless activitymay drift over time with reference to the XR activity based on adifference in resonance frequencies. In an example of a difference inresonance frequency being 20 cycles per million cycles of the crystalsbetween the application layer clock and the WCD clock (with the crystalassociated with the WCD clock having a higher resonance frequency), thewireless activity may drift 3.88 ms every 194 seconds. If the buffer2318 is 3.88 ms, the wireless activity may begin to overlap the previousXR activity after 194 seconds.

One or both of the TWT sessions may be adjusted based on the drift. Forexample, the second TWT session periodically may be adjusted to preventTWT windows from the second TWT session overlapping with TWT windowsfrom the first TWT session. In some implementations, the render devicemay measure a drift between the first plurality of TWT windows from thefirst TWT session and the second plurality of TWT windows from thesecond TWT session. As noted above, determining the first TWT sessionmay be based on the application layer clock of the render device. Thesecond TWT session may be based on a WCD clock of the render device. Therender device may adjust a timing of one or more of the first pluralityof TWT windows or the second plurality of TWT windows. For example, therender device may initiate adjusting the second TWT session to preventoverlap of the second plurality of TWT windows with the first pluralityof TWT windows.

The adjustment of the second TWT session may be at a defined interval oftime based on a measured drift. For example, if the drift is based on anapproximation of Pw, the render device may determine a defined intervalto adjust the second TWT session based on the approximation error andthe size of the buffer. In the above example of Pw being approximated tobe 16.666 ms, P_(R) being 50/3 ms, and the buffer being 3.88 ms, therender device may determine the defined interval to be less than 194seconds. In the above example of a difference in resonance frequencybeing 20 cycles per million cycles and the buffer being 3.88 ms, therender device may determine the defined interval to be less than 194 ms.In some implementations, the defined interval may be based on both typesof drift (such as being based on the feature causing the most driftbetween the two).

In addition or to the alternative of adjusting the second TWT sessionbased on a determined time interval associated with a drift, the renderdevice may attempt to determine if XR activity and wireless activitybegin to overlap. For example, the render device may provide a scheduleor the WCD otherwise may estimate when XR activity is to occur (such asthe interval at when transmitting or receiving over the second wirelesslink), and the WCD periodically may determine if the wireless activityis to overlap with estimated XR activity. The TWT windows of the secondTWT session with the AP may be moved forward or delayed based on thedetermination to prevent overlap with TWT windows of the first TWTsession.

As noted above, aspects of the present disclosure include a wirelesssystem for giving preference to communications between two devices overother devices while still sharing the wireless medium with the otherdevices. Preference may be given for communications between a renderdevice and a display device of an XR experience to meet latency andpacket loss requirements. In some implementations, preference may begiven via asynchronous channel control operations. In someimplementations, preference may be given via synchronous channel controloperations. Sharing the wireless medium may be through the use of TWTsessions or MLO techniques (such as for concurrent link support).Aspects of the present disclosure also include generating and providingfeedback associated with an XR experience between the render device andthe display device. Communications between the devices (such as therender device and the display device or the render device and the AP)may be adjusted based on the feedback to ensure meeting latency andpacket loss requirements for the XR experience. In this manner, anoverall system (such as a BSS or mesh network) including one or morerender devices and one or more display devices) may be configured tosupport an XR experience.

Implementation examples are described in the following numbered clauses:

-   -   1. A method performed by a wireless communication device for an        extended reality (XR) experience, including:        -   obtaining control of a wireless medium, where:            -   control of the wireless medium is associated with a                first priority of transmitting, over the wireless                medium, a first physical layer protocol data unit (PPDU)                of an application file from the wireless communication                device to a second device; and            -   the first priority is different than a second priority                of transmitting data from the second device to the                wireless communication device over the wireless medium;        -   providing the first PPDU to the second device; and        -   providing one or more subsequent PPDUs of the application            file to the second device, where providing the one or more            subsequent PPDUs is associated with a third priority of            transmitting the one or more subsequent PPDUs over the            wireless medium.    -   2. The method of clause 1, where:        -   the first priority is associated with a first set of            enhanced distributed channel access (EDCA) parameters;        -   the second priority is associated with a second set of EDCA            parameters; and        -   the third priority is associated with a third set of EDCA            parameters.    -   3. The method of one or more of clauses 1-2, where EDCA        parameters include one or more of:        -   an arbitration interframe spacing number (AIFSN);        -   a minimum contention window (CWmin); or a maximum contention            window (CWmax).    -   4. The method of one or more of clauses 1-2, where:        -   the first priority is associated with a first backoff            counter value, where the first backoff counter value is used            by a backoff counter of the wireless communication device to            contend for the wireless medium for the first PPDU; the            second priority is associated with a second backoff counter            value greater than the first backoff counter value; and        -   the third priority is associated with a third backoff            counter value greater than the second backoff counter value,            where the third backoff counter value is used by the backoff            counter of the wireless communication device to contend for            the wireless medium for the one or more subsequent PPDUs.    -   5. The method of one or more of clauses 1-2 or 4, where the        first backoff counter value is zero during a first transmit        opportunity (TXOP).    -   6. The method of one or more of clauses 1-2, where:        -   the wireless communication device and the second device are            included in a first basic service set (BSS);        -   the wireless communication device and the second device are            within range of a device in an other BSS (OBSS);        -   the OBSS device contends for the wireless medium to transmit            high importance classified data associated with a fourth            priority; and        -   the wireless communication device or the second device            obtains control of the wireless medium based on the first            priority or the second priority.    -   7. The method of one or more of clauses 1-2 or 6, where:        -   the wireless communication device contends for the wireless            medium to transmit one or more subsequent PPDUs associated            with the third priority;        -   the second device prevents contending for the wireless            medium; and        -   the OBSS device obtains control of the wireless medium based            on the fourth priority.    -   8. The method of one or more of clauses 1-2, further including:        -   providing a first request to send (RTS) frame to obtain            control of the wireless medium, where the first RTS frame            includes an indication of a network allocation vector (NAV)            to maintain control of the wireless medium for a first time            period, where the first time period is greater than a first            transmit opportunity (TXOP) during which the first PPDU is            provided;        -   obtaining a first clear to send (CTS) frame from the second            device after providing the first RTS frame; and        -   providing a second RTS frame after the first TXOP and before            an end of the first time period, where:            -   the second RTS frame includes an indication of the NAV                to extend the first time period to cover a plurality of                TXOPs; and            -   providing the first PPDU is after obtaining the first                CTS frame and during the first TXOP.    -   9. The method of one or more of clauses 1-2 or 8, where the        first TXOP is shortened by the wireless communication device        before providing PPDUs associated with the application file to        the second device.    -   10. The method of one or more of clauses 1-2 or 8, further        including obtaining the data from the second device after the        first TXOP and before providing the second RTS frame.    -   11. The method of one or more of clauses 1-2 or 8, further        including:        -   providing a last PPDU of the application file to the second            device, where:            -   the last PPDU includes a last media access control layer                (MAC) service data unit (MSDU) of the application file;                and            -   the last MSDU includes metadata identifying the last                MSDU of the application file;        -   preventing providing another RTS frame to extend the first            time period after providing the last MSDU to the second            device; and        -   releasing control of the wireless medium at the end of the            first time period.    -   12. The method of one or more of clauses 1-2, 8, or 11, further        including providing a contention free (CF) end beacon after        providing the last MSDU to release control of the wireless        medium.    -   13. The method of one or more of clauses 1-2, 8, or 11, further        including obtaining control of the wireless medium to provide        one or more PPDUs of a second application file to the second        device, where:        -   a first MSDU of the second application file includes            metadata identifying the first MSDU of the second            application file;        -   the first MSDU is associated with the first set of EDCA            parameters; and        -   obtaining control of the wireless medium is associated with            the first set of EDCA parameters.    -   14. The method of one or more of clauses 1-2, 8, 11, or 13,        where the wireless communication device enables RTS/CTS        signaling for the first PPDU for each application file.    -   15. The method of one or more of clauses 1-14, where:        -   the wireless communication device is included in a software            enabled access point (SAP);        -   the second device includes a head mounted display (HMD); and        -   the application file is associated with a video frame to be            displayed by the HMD.    -   16. A wireless communication device configured for an extended        reality (XR) experience, including:        -   a processing system; and        -   an interface configured to:            -   obtain control of a wireless medium, where:                -   control of the wireless medium is associated with a                    first priority of transmitting, over the wireless                    medium, a first physical layer protocol data unit                    (PPDU) of an application file from the wireless                    communication device to a second device; and                -   the first priority is different than a second                    priority of transmitting data from the second device                    to the wireless communication device over the                    wireless medium;        -   provide the first PPDU to the second device; and        -   provide one or more subsequent PPDUs of the application file            to the second device, where providing the one or more            subsequent PPDUs is associated with a third priority of            transmitting the one or more subsequent PPDUs over the            wireless medium.    -   17. The wireless communication device of clause 16, where:        -   the first priority is associated with a first set of            enhanced distributed channel access (EDCA) parameters;        -   the second priority is associated with a second set of EDCA            parameters; and        -   the third priority is associated with a third set of EDCA            parameters.    -   18. The wireless communication device of one or more of clauses        16-17, where EDCA parameters include one or more of    -   an arbitration interframe spacing number (AIFSN);        -   a minimum contention window (CWmin); or a maximum contention            window (CWmax).    -   19. The wireless communication device of one or more of clauses        16-17, where:        -   the first priority is associated with a first backoff            counter value, where the first backoff counter value is used            by a backoff counter of the wireless communication device to            contend for the wireless medium for the first PPDU; the            second priority is associated with a second backoff counter            value greater than the first backoff counter value; and        -   the third priority is associated with a third backoff            counter value greater than the second backoff counter value,            where the third backoff counter value is used by the backoff            counter of the wireless communication device to contend for            the wireless medium for the one or more subsequent PPDUs.    -   20. The wireless communication device of one or more of clauses        16-17 or 19, where the first backoff counter value is zero        during a first transmit opportunity (TXOP).    -   21. The wireless communication device of one or more of clauses        16-17, where:        -   the wireless communication device and the second device are            included in a first basic service set (BSS);        -   the wireless communication device and the second device are            within range of a device in an other BSS (OBSS);        -   the OBSS device contends for the wireless medium to transmit            high importance classified data associated with a fourth            priority; and        -   the wireless communication device or the second device            obtains control of the wireless medium based on the first            priority or the second priority.    -   22. The wireless communication device of one or more of clauses        16-17 or 21, where:        -   the wireless communication device contends for the wireless            medium to transmit one or more subsequent PPDUs associated            with the third priority; the second device prevents            contending for the wireless medium; and        -   the OBSS device obtains control of the wireless medium based            on the fourth priority.    -   23. The wireless communication device of one or more of clauses        16-17, where the interface is further configured to:        -   provide a first request to send (RTS) frame to obtain            control of the wireless medium, where the first RTS frame            includes an indication of a network allocation vector (NAV)            to maintain control of the wireless medium for a first time            period, where the first time period is greater than a first            transmit opportunity (TXOP) during which the first PPDU is            provided;        -   obtain a first clear to send (CTS) frame from the second            device after providing the first RTS frame; and        -   provide a second RTS frame after the first TXOP and before            an end of the first time period, where:            -   the second RTS frame includes an indication of the NAV                to extend the first time period to cover a plurality of                TXOPs; and            -   providing the first PPDU is after obtaining the first                CTS frame and during the first TXOP.    -   24. The wireless communication device of one or more of clauses        16-17 or 23, where the first TXOP is shortened by the wireless        communication device before providing PPDUs associated with the        application file to the second device.    -   25. The wireless communication device of clause 23, where the        interface is further configured to obtain the data from the        second device after the first TXOP and before providing the        second RTS frame.    -   26. The wireless communication device of one or more of clauses        16-17 or 23, where the interface is further configured to:        -   provide a last PPDU of the application file to the second            device, where:            -   the last PPDU includes a last media access control layer                (MAC) service data unit (MSDU) of the application file;                and            -   the last MSDU includes metadata identifying the last                MSDU of the application file;        -   prevent providing another RTS frame to extend the first time            period after providing the last MSDU to the second device;            and        -   release control of the wireless medium at the end of the            first time period.    -   27. The wireless communication device of one or more of clauses        16-17, 23, or 26, where the interface is further configured to        provide a contention free (CF) end beacon after providing the        last MSDU to release control of the wireless medium.    -   28. The wireless communication device of one or more of clauses        16-17, 23, or 26, where the interface is further configured to        obtain control of the wireless medium to provide one or more        PPDUs of a second application file to the second device, where:        -   a first MSDU of the second application file includes            metadata identifying the first MSDU of the second            application file;        -   the first MSDU is associated with the first set of EDCA            parameters; and        -   obtaining control of the wireless medium is associated with            the first set of EDCA parameters.    -   29. The wireless communication device of one or more of clauses        16-17, 23, 26, or 28, where the wireless communication device        enables RTS/CTS signaling for the first PPDU for each        application file.    -   30. The wireless communication device of one or more of clauses        16-29, where:        -   the wireless communication device is included in a software            enabled access point (SAP);        -   the second device includes a head mounted display (HMD); and        -   the application file is associated with a video frame to be            displayed by the HMD.    -   31. A method performed by a wireless communication device,        including:        -   obtaining a first physical layer protocol data unit (PPDU)            of an application file from a second device over a wireless            medium, where:            -   the second device obtains control of the wireless                medium;            -   control of the wireless medium is associated with a                first priority of transmitting the first PPDU over the                wireless medium; and            -   the first priority is different than a second priority                of transmitting data from the wireless communication                device to the second device over the wireless medium;                and        -   obtaining one or more subsequent PPDUs of the application            file from the AP, where obtaining the one or more subsequent            PPDUs is associated with a third priority of transmitting            the one or more subsequent PPDUs over the wireless medium.    -   32. The method of clause 31, where:        -   the first priority is associated with a first set of            enhanced distributed channel access (EDCA) parameters;        -   the second priority is associated with a second set of EDCA            parameters; and        -   the third priority is associated with a third set of EDCA            parameters.    -   33. The method of one or more of clauses 31-32, where EDCA        parameters include one or more of:        -   an arbitration interframe spacing number (AIFSN);        -   a minimum contention window (CWmin); or        -   a maximum contention window (CWmax).    -   34. The method of one or more of clauses 31-32, where:        -   the first priority is associated with a first backoff            counter value;        -   the second priority is associated with a second backoff            counter value greater than the first backoff counter value,            where the second backoff counter value is used by a backoff            counter of the wireless communication device in determining            when to provide the data to the AP; and        -   the third priority is associated with a third backoff            counter value greater than the second backoff counter value.    -   35. The method of one or more of clauses 31-32 or 34, where the        first backoff counter value is zero during a first transmit        opportunity (TXOP).    -   36. The method of one or more of clauses 31-32, where:        -   the wireless communication device and the second device are            included in a first basic service set (BSS);        -   the wireless communication device and the second device are            within range of a device in an other BSS (OBSS);        -   the OBSS device contends for the wireless medium to transmit            high importance classified data associated with a fourth            priority; and        -   the wireless communication device or the second device            obtains control of the wireless medium based on the first            priority or the second priority.    -   37. The method of one or more of clauses 31-32 or 36, where:        -   the second device contends for the wireless medium to            transmit one or more subsequent PPDUs associated with the            third priority;        -   the wireless communication device prevents contending for            the wireless medium; and        -   the OBSS device obtains control of the wireless medium based            on the fourth priority.    -   38. The method of one or more of clauses 31-32, further        including:        -   obtaining a first request to send (RTS) frame from the AP,            where the first RTS frame includes an indication of a            network allocation vector (NAV) to maintain control of the            wireless medium for a first time period, where the first            time period is greater than a first transmit opportunity            (TXOP) during which the first PPDU is obtained from the AP;        -   providing a first clear to send (CTS) frame to the second            device after obtaining the first RTS frame; and        -   obtaining, from the AP, a second RTS frame after the first            TXOP and before an end of the first time period, where:            -   the second RTS frame includes an indication of the NAV                to extend the first time period to cover a plurality of                TXOPs; and            -   obtaining the first PPDU is after providing the first                CTS frame and during the first TXOP.    -   39. The method of one or more of clauses 31-32 or 38, where the        first TXOP is shortened by the second device before the second        device provides PPDUs associated with the application file to        the wireless communication device.    -   40. The method of one or more of clauses 31-32 or 38, further        including providing the data to the second device after the        first TXOP and before obtaining the second RTS frame.    -   41. The method of one or more of clauses 31-32 or 38, further        including:        -   obtaining a last PPDU of the application file from the AP,            where:            -   the last PPDU includes a last media access control layer                (MAC) service data unit (MSDU) of the application file;            -   the last MSDU includes metadata identifying the last                MSDU of the application file;            -   the second device prevents providing another RTS frame                to extend the first time period after providing the last                MSDU to the wireless communication device; and            -   the second device releases control of the wireless                medium at the end of the first time period.    -   42. The method of one or more of clauses 31-32, 28, or 41,        further including obtaining a contention free (CF) end beacon        from the second device after obtaining the last MSDU, where the        CF end beacon is used to release control of the wireless medium.    -   43. The method of one or more of clauses 31-32, 38, or 41,        where:        -   the second device obtains control of the wireless medium to            provide one or more PPDUs of a second application file to            the wireless communication device;        -   a first MSDU of the second application file includes            metadata identifying the first MSDU of the second            application file;        -   the first MSDU is associated with the first set of EDCA            parameters; and        -   obtaining control of the wireless medium by the second            device is associated with the first set of EDCA parameters.    -   44. The method of one or more of clauses 31-43, where:        -   the second device includes a software enabled AP (SAP);        -   the wireless communication device is included in a head            mounted display (HMD); and        -   the application file is associated with a video frame to be            displayed by the HMD.    -   45. A wireless communication device configured for an extended        reality (XR) experience, including:        -   a processing system; and        -   an interface configured to:            -   obtain a first physical layer protocol data unit (PPDU)                of an application file from a second device over a                wireless medium, where:                -   the second device obtains control of the wireless                    medium;                -   control of the wireless medium is associated with a                    first priority of transmitting the first PPDU over                    the wireless medium; and                -   the first priority is different than a second                    priority of transmitting data from the wireless                    communication device to the second device over the                    wireless medium; and            -   obtain one or more subsequent PPDUs of the application                file from the AP, where obtaining the one or more                subsequent PPDUs is associated with a third priority of                transmitting the one or more subsequent PPDUs over the                wireless medium.    -   46. The wireless communication device of clause 45, where:        -   the first priority is associated with a first set of            enhanced distributed channel access (EDCA) parameters;        -   the second priority is associated with a second set of EDCA            parameters; and        -   the third priority is associated with a third set of EDCA            parameters.    -   47. The wireless communication device of one or more of clauses        45-46, where EDCA parameters include one or more of:        -   an arbitration interframe spacing number (AIFSN);        -   a minimum contention window (CWmin); or        -   a maximum contention window (CWmax).    -   48. The wireless communication device of one or more of clauses        45-46, where:        -   the first priority is associated with a first backoff            counter value;        -   the second priority is associated with a second backoff            counter value greater than the first backoff counter value,            where the second backoff counter value is used by a backoff            counter of the wireless communication device in determining            when to provide the data to the AP; and        -   the third priority is associated with a third backoff            counter value greater than the second backoff counter value.    -   49. The wireless communication device of one or more of clauses        45-46 or 48, where the first backoff counter value is zero        during a first transmit opportunity (TXOP).    -   50. The wireless communication device of one or more of clauses        45-46, where:        -   the wireless communication device and the second device are            included in a first basic service set (BSS);        -   the wireless communication device and the second device are            within range of a device in an other BSS (OBSS);        -   the OBSS device contends for the wireless medium to transmit            high importance classified data associated with a fourth            priority; and        -   the wireless communication device or the second device            obtains control of the wireless medium based on the first            priority or the second priority.    -   51. The wireless communication device of one or more of clauses        45-46 or 50, where:        -   the second device contends for the wireless medium to            transmit one or more subsequent PPDUs associated with the            third priority;        -   the wireless communication device prevents contending for            the wireless medium; and        -   the OBSS device obtains control of the wireless medium based            on the fourth priority.    -   52. The wireless communication device of one or more of clauses        45-46, where the interface is further configured to:        -   obtain a first request to send (RTS) frame from the AP,            where the first RTS frame includes an indication of a            network allocation vector (NAV) to maintain control of the            wireless medium for a first time period, where the first            time period is greater than a first transmit opportunity            (TXOP) during which the first PPDU is obtained from the AP;        -   provide a first clear to send (CTS) frame to the second            device after obtaining the first RTS frame; and        -   obtain, from the AP, a second RTS frame after the first TXOP            and before an end of the first time period, where:            -   the second RTS frame includes an indication of the NAV                to extend the first time period to cover a plurality of                TXOPs; and            -   obtaining the first PPDU is after providing the first                CTS frame and during the first TXOP.    -   53. The wireless communication device of one or more of clauses        45-46 or 52, where the first TXOP is shortened by the second        device before the second device provides PPDUs associated with        the application file to the wireless communication device.    -   54. The wireless communication device of one or more of clauses        45-46 or 52, where the interface is further configured to        provide the data to the second device after the first TXOP and        before obtaining the second RTS frame.    -   55. The wireless communication device of one or more of clauses        45-46 or 52, where the interface is further configured to:        -   obtain a last PPDU of the application file from the AP,            where:            -   the last PPDU includes a last media access control layer                (MAC) service data unit (MSDU) of the application file;            -   the last MSDU includes metadata identifying the last                MSDU of the application file;            -   the second device prevents providing another RTS frame                to extend the first time period after providing the last                MSDU to the wireless communication device; and            -   the second device releases control of the wireless                medium at the end of the first time period.    -   56. The wireless communication device of one or more of clauses        45-46, 52, or 55, where the interface is further configured to        obtain a contention free (CF) end beacon from the second device        after obtaining the last MSDU, where the CF end beacon is used        to release control of the wireless medium.    -   57. The wireless communication device of one or more of clauses        45-46, 52, or 55, where:        -   the second device obtains control of the wireless medium to            provide one or more PPDUs of a second application file to            the wireless communication device;        -   a first MSDU of the second application file includes            metadata identifying the first MSDU of the second            application file;        -   the first MSDU is associated with the first set of EDCA            parameters; and        -   obtaining control of the wireless medium by the second            device is associated with the first set of EDCA parameters.    -   58. The wireless communication device of one or more of clauses        45-57, where:        -   the second device includes a software enabled AP (SAP);        -   the wireless communication device is included in a head            mounted display (HMD); and        -   the application file is associated with a video frame to be            displayed by the HMD.    -   59. A method performed by a device for an extended reality (XR)        experience, including:        -   obtaining, from a second device, uplink (UL) data over a            wireless medium; and        -   providing, to the second device, downlink (DL) data            including physical layer protocol data units (PPDUs) over            the wireless medium, where:            -   one or more PPDUs are provided to the second device                during a current target wake time (TWT) window; and            -   a beginning of the current TWT window is associated with                one of:                -   when a first PPDU of the one or more PPDUs is                    provided to the second device; or                -   when the first PPDU is provided from an application                    layer to a media access control layer (MAC) of the                    device.    -   60. The method of clause 59, further including rendering video        frames to be displayed by the second device, where:        -   the device includes a render device;        -   the second device includes a display device;        -   the UL data includes pose data frames; and        -   the rendering of the video frames is associated with the            obtained pose data frames, where:            -   a first video frame of the video frames includes a                plurality of slices;            -   rendering of the first video frame is associated with a                first pose data frame most recently obtained from the                second device; and            -   one or more PPDUs are associated with one or more of the                plurality of slices.    -   61. The method of one or more of clauses 59-60, further        including:        -   providing, to the second device, a packet including a MAC            header including a power management (PM) field indicating            that the second device is not to enter into a low power mode            after the current TWT window; and        -   providing, to the second device, a PPDU associated with a            video slice of the first video frame after the current TWT            window and before a next TWT window.    -   62. The method of one or more of clauses 59-60, where the        beginning of the current TWT window is further associated with a        motion to render (M2R) latency for the first video frame.    -   63. The method of one or more of clauses 59-60 or 62, further        including synchronizing an application layer clock and a        wireless communication device (WCD) clock of the device, where:        -   the application layer clock is used by the device for timing            of rendering the video frames; and        -   the WCD clock is used by the device for timing of wireless            communications with the second device.    -   64. The method of one or more of clauses 59-60, 62, or 63,        where:        -   the pose data frames are obtained at a first frequency; and        -   the video frames are rendered at the first frequency, where            each obtained pose data frame is associated with a rendered            video frame.    -   65. The method of one or more of clauses 59-60, 62, or 63, where        synchronizing the application layer clock and the WCD clock of        the device includes synchronizing the WCD clock to the        application layer clock.    -   66. The method of one or more of clauses 59-60, 62, 63, or 65,        where synchronizing the WCD clock to the application layer clock        includes:        -   aligning the beginning of the current TWT window to a first            time before a render time to begin rendering the first video            frame, where the first time precedes the render time by a            first offset and where the first offset is associated with            the M2R latency.    -   67. The method of one or more of clauses 59-60, 62, 63, 65, or        66, further including obtaining the first pose data frame during        the beginning of the current TWT window.    -   68. The method of one or more of clauses 59-60, 62, 63, or        65-67, further including:        -   obtaining an additional pose data frame during the current            TWT window; and        -   rendering at least a portion of a second video frame during            a next TWT window, where:            -   the second video frame is associated with the additional                pose data frame; and            -   the additional pose data frame is the most recently                obtained pose data frame before rendering the second                video frame.    -   69. The method of one or more of clauses 59-60, 62, or 63, where        synchronizing the application layer clock and the WCD clock of        the device includes synchronizing the application layer clock to        the WCD clock, where synchronizing the application layer clock        to the WCD clock is associated with a timing synchronization        function (TSF) at the MAC of the device.    -   70. The method of one or more of clauses 59-60, 62, 63, or 69,        where synchronizing the application layer clock to the WCD clock        includes:        -   aligning a render time to begin rendering the first video            frame to a first time after the beginning of the current TWT            window, where the first time succeeds the beginning of the            current TWT window by a first offset and where the first            offset is associated with the M2R latency.    -   71. The method of one or more of clauses 59-60, 62, or 63,        further including periodically synchronizing the application        layer clock and the WCD clock of the device, where synchronizing        the application layer clock and the WCD clock is associated with        a drift between the application layer clock and the WCD clock        being greater than a drift threshold since a last        synchronization between the application layer clock and the WCD        clock.    -   72. The method of one or more of clauses 59-71, where:        -   the device includes a software enabled AP (SAP); and        -   the second device includes a head mounted display (HMD) to            display the video frames.    -   73. A device configured for an extended reality (XR) experience,        including:        -   a processing system; and        -   an interface configured to:            -   obtain, from a second device, uplink (UL) data over a                wireless medium; and            -   provide, to the second device, downlink (DL) data                including physical layer protocol data units (PPDUs)                over the wireless medium,        -   where:            -   one or more PPDUs are provided to the second device                during a current target wake time (TWT) window; and            -   a beginning of the current TWT window is associated with                one of                -   when a first PPDU of the one or more PPDUs is                    provided to the second device; or                -   when the first PPDU is provided from an application                    layer to a media access control layer (MAC) of the                    device.    -   74. The device of clause 73, where the processing system is        configured to render video frames to be displayed by the second        device, where:        -   the device includes a render device;        -   the second device includes a display device;        -   the UL data includes pose data frames; and        -   the rendering of the video frames is associated with the            obtained pose data frames, where:            -   a first video frame of the video frames includes a                plurality of slices;            -   rendering of the first video frame is associated with a                first pose data frame most recently obtained from the                second device; and            -   one or more PPDUs are associated with one or more of the                plurality of slices.    -   75. The device of one or more of clauses 73-74, where the        interface is further configured to:        -   provide, to the second device, a packet including a MAC            header including a power management (PM) field indicating            that the second device is not to enter into a low power mode            after the current TWT window; and        -   provide, to the second device, a PPDU associated with a            video slice of the first video frame after the current TWT            window and before a next TWT window.    -   76. The device of one or more of clauses 73-74, where the        beginning of the current TWT window is further associated with a        motion to render (M2R) latency for the first video frame.    -   77. The device of one or more of clauses 73-74 or 76, where the        device is configured to synchronize an application layer clock        and a wireless communication device (WCD) clock of the device,        where:        -   the application layer clock is used by the device for timing            of rendering the video frames; and        -   the WCD clock is used by the device for timing of wireless            communications with the second device.    -   78. The device of one or more of clauses 73-74, 76, or 77,        where:        -   the pose data frames are obtained at a first frequency; and        -   the video frames are rendered at the first frequency, where            each obtained pose data frame is associated with a rendered            video frame.    -   79. The device of one or more of clauses 73-74, 76, or 77, where        synchronizing the application layer clock and the WCD clock of        the device includes synchronizing the WCD clock to the        application layer clock.    -   80. The device of one or more of clauses 73-74, 76, 77, or 79,        where synchronizing the WCD clock to the application layer clock        includes:        -   aligning the beginning of the current TWT window to a first            time before a render time to begin rendering the first video            frame, where the first time precedes the render time by a            first offset and where the first offset is associated with            the M2R latency.    -   81. The device of one or more of clauses 73-74, 76, 77, 79, or        80, where the interface is further configured to obtain the        first pose data frame during the beginning of the current TWT        window.    -   82. The device of one or more of clauses 73-74, 76, 77, or        79-81, where:        -   the interface is further configured to obtain an additional            pose data frame during the current TWT window; and        -   the processing system is further configured to render at            least a portion of a second video frame during a next TWT            window, where:            -   the second video frame is associated with the additional                pose data frame; and            -   the additional pose data frame is the most recently                obtained pose data frame before rendering the second                video frame.    -   83. The device of one or more of clauses 73-74, 76, or 77, where        synchronizing the application layer clock and the WCD clock of        the device includes synchronizing the application layer clock to        the WCD clock, where synchronizing the application layer clock        to the WCD clock is associated with a timing synchronization        function (TSF) at the MAC of the device.    -   84. The device of one or more of clauses 73-74, 76, 77, or 83,        where synchronizing the application layer clock to the WCD clock        includes:        -   aligning a render time to begin rendering the first video            frame to a first time after the beginning of the current TWT            window, where the first time succeeds the beginning of the            current TWT window by a first offset and where the first            offset is associated with the M2R latency.    -   85. The device of one or more of clauses 73-74, 76, or 77, where        the device is configured to periodically synchronize the        application layer clock and the WCD clock of the device, where        synchronizing the application layer clock and the WCD clock is        associated with a drift between the application layer clock and        the WCD clock being greater than a drift threshold since a last        synchronization between the application layer clock and the WCD        clock.    -   86. The device of one or more of clauses 73-85, where:        -   the device includes a software enabled AP (SAP); and        -   the second device includes a head mounted display (HMD) to            display the video frames.    -   87. A method performed by a device for an extended reality (XR)        experience, including:        -   providing uplink (UL) data to a second device over a            wireless medium; and        -   obtaining, from the second device, downlink (DL) data            including physical layer protocol data units (PPDUs) over            the wireless medium, where:            -   one or more PPDUs are obtained from the second device                during a current target wake time (TWT) window; and            -   a beginning of the current TWT window is associated with                one of:                -   when a first PPDU of the one or more PPDUs is                    provided by the second device; or                -   when the first PPDU is provided from an application                    layer to a media access control layer (MAC) of the                    second device.    -   88. The method of clause 87, where the second device is to        render video frames to be displayed by the device, where:        -   the second device includes a render device;        -   the device includes a display device;        -   the UL data includes pose data frames; and        -   the rendering of the video frames is associated with the            provided pose data frames, where:            -   a first video frame of the video frames includes a                plurality of slices;            -   rendering of the first video frame is associated with a                first pose data frame most recently obtained by the                second device; and            -   one or more PPDUs are associated with one or more of the                plurality of slices.    -   89. The method of one or more of clauses 87-88, further        including:        -   obtaining, from the second device, a packet including a MAC            header including a power management (PM) field indicating            that the second device is not to enter into a low power mode            after the current TWT window; and        -   obtaining, from the second device, a PPDU associated with a            video slice of the first video frame after the current TWT            window and before a next TWT window.    -   90. The method of one or more of clauses 87-88, where the        beginning of the current TWT window is further associated with a        motion to render (M2R) latency for the first video frame.    -   91. The method of one or more of clauses 87-88 or 90, further        including synchronizing an application layer clock and a WCD        clock of the device, where:        -   the application layer clock is used by the device for timing            of displaying the video frames; and        -   the WCD clock is used by the device for timing of wireless            communications with the second device.    -   92. The method of one or more of clauses 87-88, 90, or 91,        where:        -   the pose data frames are provided at a first frequency; and        -   the video frames are rendered by the second device at the            first frequency, where each pose data frame obtained by the            second device is associated with a rendered video frame.    -   93. The method of one or more of clauses 87-88, 90, or 91, where        synchronizing the application layer clock and the WCD clock of        the device includes synchronizing the WCD clock to the        application layer clock.    -   94. The method of one or more of clauses 87-88, 90, 91, or 93,        where synchronizing the WCD clock to the application layer clock        includes:    -   aligning the beginning of the current TWT window to a first time        the first pose data is provided to the second device, where:        -   the first time precedes a render time that the second device            is to begin rendering the first video frame;        -   the first time precedes the render time by a first offset;            and        -   the first offset is associated with the M2R latency.    -   95. The method of one or more of clauses 87-88, 90, 91, or 93,        where the second device begins to render the first video frame        upon one of:        -   obtaining the first pose data frame during the beginning of            the current TWT window; or        -   a timeout from the beginning of the current TWT window            occurring before obtaining a pose data frame.    -   96. The method of one or more of clauses 87-88, 90, 91, or 93,        further including indicating, to the second device, a time of        the beginning of the current TWT window, where:        -   the indication of the time is associated with a timing            synchronization function (TSF) at the MAC of the device            after the WCD clock is synchronized to the application layer            clock;        -   a WCD clock of the second device is synchronized to the WCD            clock of the device, where synchronization of the WCD clocks            are associated with the TSF of the device and a TSF at a MAC            of the second device; and        -   an application layer clock of the second device is            synchronized to the WCD clock of the AP, where            synchronization of the application layer clock of the second            device to the WCD clock of the second device is associated            with the TSF of the second device.    -   97. The method of one or more of clauses 87-88, 90, or 91, where        synchronizing the application layer clock and the WCD clock of        the device includes synchronizing the application layer clock to        the WCD clock, where synchronizing the application layer clock        to the WCD clock is associated with a timing synchronization        function (TSF) at the MAC of the device.    -   98. The method of one or more of clauses 87-88, 90, 91, or 97,        where synchronizing the application layer clock to the WCD clock        includes:        -   aligning a display time to a time associated with the            current TWT window.    -   99. The method of one or more of clauses 87-88, 90, or 91,        further including periodically synchronizing the application        layer clock and the WCD clock of the device, where synchronizing        the application layer clock and the WCD clock is associated with        a drift between the application layer clock and the WCD clock        being greater than a drift threshold since a last        synchronization between the application layer clock and the WCD        clock.    -   100. The method of one or more of clauses 87-99, where:        -   the second device includes a software enabled AP (SAP); and        -   the device includes ahead mounted display (HMD) to display            the video frames.    -   101. A device configured for an extended reality (XR)        experience, including:        -   a processing system; and        -   an interface configured to:            -   provide uplink (UL) data to a second device over a                wireless medium; and            -   obtain, from the second device, downlink (DL) data                including physical layer protocol data units (PPDUs)                over the wireless medium, where:                -   one or more PPDUs are obtained from the second                    device during a current target wake time (TWT)                    window; and                -   a beginning of the current TWT window is associated                    with one of:                -    when a first PPDU of the one or more PPDUs is                    provided by the second device; or                -    when the first PPDU is provided from an application                    layer to a media access control layer (MAC) of the                    second device.    -   102. The device of clause 101, where the second device is to        render video frames to be displayed by the device, where:        -   the second device includes a render device;        -   the device includes a display device;        -   the UL data includes pose data frames; and        -   the rendering of the video frames is associated with the            provided pose data frames, where:            -   a first video frame of the video frames includes a                plurality of slices;            -   rendering of the first video frame is associated with a                first pose data frame most recently obtained by the                second device; and            -   one or more PPDUs are associated with one or more of the                plurality of slices.    -   103. The device of one or more of clauses 101-102, where the        interface is further configured to:        -   obtain, from the second device, a packet including a MAC            header including a power management (PM) field indicating            that the second device is not to enter into a low power mode            after the current TWT window; and        -   obtain, from the second device, a PPDU associated with a            video slice of the first video frame after the current TWT            window and before a next TWT window.    -   104. The device of one or more of clauses 101-102, where the        beginning of the current TWT window is further associated with a        motion to render (M2R) latency for the first video frame.    -   105. The device of one or more of clauses 101-102 or 104, where        the device is configured to synchronize an application layer        clock and a WCD clock of the device, where:        -   the application layer clock is used by the device for timing            of displaying the video frames; and        -   the WCD clock is used by the device for timing of wireless            communications with the second device.    -   106. The device of one or more of clauses 101-102, 104, or 105,        where:        -   the pose data frames are provided at a first frequency; and        -   the video frames are rendered by the second device at the            first frequency, where each pose data frame obtained by the            second device is associated with a rendered video frame.    -   107. The device of one or more of clauses 101-102, 104, or 105,        where synchronizing the application layer clock and the WCD        clock of the device includes synchronizing the WCD clock to the        application layer clock.    -   108. The device of one or more of clauses 101-102, 104, 105, or        107, where synchronizing the WCD clock to the application layer        clock includes:        -   aligning the beginning of the current TWT window to a first            time the first pose data is provided to the second device,            where:            -   the first time precedes a render time that the second                device is to begin rendering the first video frame;            -   the first time precedes the render time by a first                offset; and            -   the first offset is associated with the M2R latency.    -   109. The device of one or more of clauses 101-102, 104, 105, or        107, where the second device begins to render the first video        frame upon one of:        -   obtaining the first pose data frame during the beginning of            the current TWT window; or        -   a timeout from the beginning of the current TWT window            occurring before obtaining a pose data frame.    -   110. The device of one or more of clauses 101-102, 104, 105, or        107, where the interface is further configured to indicate, to        the second device, a time of the beginning of the current TWT        window, where:        -   the indication of the time is associated with a timing            synchronization function (TSF) at the MAC of the device            after the WCD clock is synchronized to the application layer            clock;        -   a WCD clock of the second device is synchronized to the WCD            clock of the device, where synchronization of the WCD clocks            are associated with the TSF of the device and a TSF at a MAC            of the second device; and        -   an application layer clock of the second device is            synchronized to the WCD clock of the second device, where            synchronization of the application layer clock of the second            device to the WCD clock of the second device is associated            with the TSF of the second device.    -   111. The device of one or more of clauses 101-102, 104, or 105,        where synchronizing the application layer clock and the WCD        clock of the device includes synchronizing the application layer        clock to the WCD clock, where synchronizing the application        layer clock to the WCD clock is associated with a timing        synchronization function (TSF) at the MAC of the device.    -   112. The device of one or more of clauses 101-102, 104, 105, or        111, where synchronizing the application layer clock to the WCD        clock includes:        -   aligning a display time to a time associated with the            current TWT window.    -   113. The device of one or more of clauses 101-102, 104, or 105,        where the device is configured to periodically synchronize the        application layer clock and the WCD clock of the device, where        synchronizing the application layer clock and the WCD clock is        associated with a drift between the application layer clock and        the WCD clock being greater than a drift threshold since a last        synchronization between the application layer clock and the WCD        clock.    -   114. The device of one or more of clauses 101-113, where:        -   the second device includes a software enabled AP (SAP); and        -   the device includes a head mounted display (HMD) to display            the video frames.    -   115. A method performed by a device, including:        -   rendering a plurality of video frames to be provided to a            second device; splitting each video frame of the plurality            of video frames into a plurality of video slices; and        -   for each video slice of the plurality of video slices:            -   generating a plurality of PPDUs to include the video                slice, where:                -   each PPDU includes one or more media access control                    layer (MAC) service data units (MSDUs) associated                    with the video slice; and                -   the video slice is identified by a port number and a                    differentiated services field codepoint (DSCP) value                    included in each MSDU of the plurality of PPDU; and                    queuing the MSDUs for transmission to the second                    device.    -   116. The method of clause 115, where queuing the MSDUs includes        generating a MSDU queue in software for each video slice, where        each MSDU queue is identified by an internet protocol (IP)        address, port number, and DSCP value.    -   117. The method of one or more of clauses 115-116, where each        video slice is associated with a traffic identifier (TID) that        is associated with an access category (AC) of the video slice.    -   118. The method of one or more of clauses 115-117, where the AC        of the video slice is associated with a priority of the video        slice.    -   119. The method of one or more of clauses 115-118, where the        priority of the video slice depends on whether the video slice        is a i-slice or a p-slice.    -   120. The method of one or more of clauses 115-119, further        including:        -   rendering a first p-slice;        -   generating a first MSDU queue associated with the first            p-slice;        -   rendering a second p-slice after rendering the first            p-slice; and        -   flushing the first MSDU queue after rendering the second            p-slice and before providing, to the second device, a PPDU            including one or more MSDUs associated with the first            p-slice.    -   121. The method of one or more of clauses 115-119, further        including:        -   rendering a first i-slice;        -   generating a first MSDU queue associated with the first            i-slice;        -   rendering a second i-slice or p-slice after rendering the            first i-slice;        -   generating a second MSDU queue associated with the second            i-slice; and        -   providing, to the second device, a PPDU including one or            more MSDUs associated with the first i-slice after            generating the second MSDU queue.    -   122. The method of one or more of clauses 115-119, where for a        PPDU associated with a video slice:        -   the PPDU is attempted to be transmitted to the second device            up to a threshold number of times; and        -   the device flushes a MSDU queue associated with the video            slice after unsuccessfully attempting to transmit the PPDU            to the second device the threshold number of times.    -   123. The method of one or more of clauses 115-119 or 122,        further including:        -   generating a replacement video slice after flushing the MSDU            queue; and        -   generating a replacement MSDU queue associated with the            replacement video slice.    -   124. The method of one or more of clauses 115-119 or 122,        further including indicating, to the second device, that the        MSDU queue is flushed.    -   125. The method of clause 115, further including using forward        error correction (FEC) for transmitting one or more PPDUs to the        second device.    -   126. The method of one or more of clauses 115 or 125, where use        of FEC for transmitting one or more PPDUs to the second device        is associated with one or more of:        -   a link quality between the device and the second device;        -   one or more parameters of the second device; or        -   one or more parameters of the plurality of video frames.    -   127. The method of one or more of clauses 115-126, where:        -   the device includes a software enabled access point (SAP);            and        -   the second device includes a head mounted display (HMD).    -   128. A device configured for an extended reality (XR)        experience, including:        -   an interface; and        -   a processing system configured to:            -   render a plurality of video frames to be provided to a                second device;            -   split each video frame of the plurality of video frames                into a plurality of video slices; and            -   for each video slice of the plurality of video slices:                -   generate a plurality of PPDUs to include the video                    slice, where:                -    each PPDU includes one or more media access control                    layer (MAC) service data units (MSDUs) associated                    with the video slice; and                -    the video slice is identified by a port number and                    a differentiated services field codepoint (DSCP)                    value included in each MSDU of the PPDU; and                -   queue the MSDUs for transmission to the second                    device.    -   129. The device of clause 128, where queuing the MSDUs includes        generating a MSDU queue in software for each video slice, where        each MSDU queue is identified by an internet protocol (IP)        address, port number, and DSCP value.    -   130. The device of one or more of clauses 128-129, where each        video slice is associated with a traffic identifier (TID) that        is associated with an access category (AC) of the video slice.    -   131. The device of one or more of clauses 128-130, where the AC        of the video slice is associated with a priority of the video        slice.    -   132. The device of one or more of clauses 128-131, where the        priority of the video slice depends on whether the video slice        is a i-slice or a p-slice.    -   133. The device of one or more of clauses 128-132, where the        processing system is further configured to:        -   render a first p-slice;        -   generate a first MSDU queue associated with the first            p-slice;        -   render a second p-slice after rendering the first p-slice;            and        -   flush the first MSDU queue after rendering the second            p-slice and before providing, to the second device, a PPDU            including one or more MSDUs associated with the first            p-slice.    -   134. The device of one or more of clauses 128-132, where:        -   the processing system is further configured to:            -   render a first i-slice;            -   generate a first MSDU queue associated with the first                i-slice;            -   render a second i-slice or p-slice after rendering the                first i-slice; and            -   generate a second MSDU queue associated with the second                i-slice; and        -   the interface is configured to provide, to the second            device, a PPDU including one or more MSDUs associated with            the first i-slice after generating the second MSDU queue.    -   135. The device of one or more of clauses 128-132, where for a        PPDU associated with a video slice:        -   the interface is configured to attempt to transmit the PPDU            to the second device up to a threshold number of times; and        -   the processing system is further configured to flush a MSDU            queue associated with the video slice after unsuccessfully            attempting to transmit the PPDU to the second device the            threshold number of times.    -   136. The device of one or more of clauses 128-132 or 135, where        the processing system is further configured to:        -   generate a replacement video slice after flushing the MSDU            queue; and        -   generate a replacement MSDU queue associated with the            replacement video slice.    -   137. The device of one or more of clauses 128-132 or 135, where        the interface is further configured to indicate, to the second        device, that the MSDU queue is flushed.    -   138. The device of clause 128, where the device is configured to        use forward error correction (FEC) for transmitting one or more        PPDUs to the second device.    -   139. The device of one or more of clauses 128 or 138, where use        of FEC for transmitting one or more PPDUs to the second device        is associated with one or more of:        -   a link quality between the device and the second device;        -   one or more parameters of the second device; or        -   one or more parameters of the plurality of video frames.    -   140. The device of one or more of clauses 128-139, where:        -   the device includes a software enabled access point (SAP);            and        -   the second device includes a head mounted display (HMD).    -   141. A method performed by a device, including:        -   obtaining, from a second device, one or more physical layer            (PHY) protocol data units (PPDUs) associated with a video            frame, where:        -   the second device renders a plurality of video frames to be            provided to the device;        -   the second device splits each video frame of the plurality            of video frames into a plurality of video slices; and        -   for each video slice of the plurality of video slices:            -   the second device generates a plurality of PPDUs to                include the video slice, where:                -   each PPDU includes one or more media access control                    layer (MAC) service data units (MSDUs) associated                    with the video slice; and                -   the video slice is identified by a port number and a                    differentiated services field codepoint (DSCP) value                    included in each MSDU of the plurality of PPDUs; and            -   the second device queues the MSDUs for transmission to                the device.    -   142. The method of clause 141, where queuing the MSDUs includes        generating a MSDU queue in software for each video slice, where        each MSDU queue is identified by an internet protocol (IP)        address, port number, and DSCP value.    -   143. The method of one or more of clauses 141-142, where each        video slice is associated with a traffic identifier (TID) that        is associated with an access category (AC) of the video slice.    -   144. The method of one or more of clauses 141-143, further        including:        -   obtaining, at a reorder (REO) queue of the device, a portion            of MSDUs associated with a video slice; and        -   flushing the REO queue after not obtaining a remainder of            the MSDUs associated with the video slice before a REO            timeout occurs.    -   145. The method of one or more of clauses 141-144, where the REO        timeout is associated with the AC of the video slice.    -   146. The method of one or more of clauses 141-143, further        including:        -   obtaining, at a reorder (REO) queue of the device, one or            more MSDUs from the second device;        -   obtaining an indication that a transmit queue associated            with the one or more MSDUs is flushed by the second device;            and        -   flushing the REO queue after obtaining the indication.    -   147. The method of clause 141, further including using forward        error correction (FEC) for obtaining one or more PPDUs from the        second device.    -   148. The method of one or more of clauses 141 or 147, where use        of FEC for obtaining one or more PPDUs from the second device is        associated with one or more of:        -   a link quality between the device and the second device;        -   one or more parameters of the second device; or        -   one or more parameters of the plurality of video frames.    -   149. The method of one or more of clauses 141-148, where:        -   the second device includes a software enabled access point            (SAP); and        -   the device includes a head mounted display (HMD).    -   150. A device configured for an extended reality (XR)        experience, including:        -   a processing system; and        -   an interface configured to:            -   obtain, from a second device, one or more physical layer                (PHY) protocol data units (PPDUs) associated with a                video frame, where:                -   the second device renders a plurality of video                    frames to be provided to the device;                -   the second device splits each video frame of the                    plurality of video frames into a plurality of video                    slices; and                -   for each video slice of the plurality of video                    slices:                -    the second device generates a plurality of PPDUs to                    include the video slice, where:                -    each PPDU includes one or more media access control                    layer (MAC) service data units (MSDUs) associated                    with the video slice; and                -    the video slice is identified by a port number and                    a differentiated services field codepoint (DSCP)                    value included in each MSDU of the plurality of                    PPDUs; and                -    the second device queues the MSDUs for transmission                    to the device.    -   151. The device of clause 150, where queuing the MSDUs includes        generating a MSDU queue in software for each video slice, where        each MSDU queue is identified by an internet protocol (IP)        address, port number, and DSCP value.    -   152. The device of one or more of clauses 150-151, where each        video slice is associated with a traffic identifier (TID) that        is associated with an access category (AC) of the video slice.    -   153. The device of one or more of clauses 150-152, where:        -   the interface is further configured to obtain, at a reorder            (REO) queue of the device, a portion of MSDUs associated            with a video slice; and        -   the processing system is configured to flush the REO queue            after not obtaining a remainder of the MSDUs associated with            the video slice before a REO timeout occurs.    -   154. The device of one or more of clauses 150-153, where the REO        timeout is associated with the AC of the video slice.    -   155. The device of one or more of clauses 150-152, where:        -   the interface is further configured to:            -   obtain, at a reorder (REO) queue of the device, one or                more MSDUs from the second device; and            -   obtain an indication that a transmit queue associated                with the one or more MSDUs is flushed by the second                device; and        -   the processing system is configured to flush the REO queue            after obtaining the indication.    -   156. The device of clause 150, where the device is configured to        use forward error correction (FEC) for obtaining one or more        PPDUs from the second device.    -   157. The device of one or more of clauses 150 or 156, where use        of FEC for obtaining one or more PPDUs from the second device is        associated with one or more of:        -   a link quality between the device and the second device;        -   one or more parameters of the second device; or        -   one or more parameters of the plurality of video frames.    -   158. The device of one or more of clauses 150-157, where:        -   the second device includes a software enabled access point            (SAP); and        -   the device includes a head mounted display (HMD).    -   159. A method performed by a device, including:        -   attempting to provide a plurality of PPDUs associated with            one or more video frames of an extended reality (XR)            experience to a second device; and measuring one or more of:            -   a PPDU transmission latency associated with attempting                to provide the plurality of PPDUs; or            -   a PPDU transmission drop associated with attempting to                provide the plurality of PPDUs,            -   where one or more parameters of the XR experience are                adjusted and associated with one or more of the                measurements.    -   160. The method of clause 159, further including:        -   obtaining one or more pose data frames from the second            device, where each of the one or more video frames is            associated with a pose data frame of the one or more pose            data frames; and        -   measuring a pose data frame delivery latency associated with            obtaining the one or more pose data frames.    -   161. The method of one or more of clauses 159-160, further        including measuring a frequency of missing or delayed pose data        frames associated with obtaining the one or more pose data        frames.    -   162. The method of one or more of clauses 159-161, further        including providing an indication of the one or more        measurements to the second device in an aggregated control        (A-Control) field of a header of one or more packets provided to        the second device.    -   163. The method of one or more of clauses 159-162, where the        A-Control field includes a reserved control identifier (ID) for        the indication of the one or more measurements.    -   164. The method of one or more of clauses 159-162, where:        -   the one or more measurements include a link quality            measurement of a link quality between the device and the            second device; and        -   the A-Control field includes an indication of the link            quality.    -   165. The method of one or more of clauses 159-162 or 164, where        the A-Control field includes a bit reserved to indicate the link        quality.    -   166. The method of one or more of clauses 159-162, where the one        or more packets are included in one or more of:        -   a request to send (RTS) or clear to send (CTS) frame;        -   a data frame; or        -   a block acknowledgement (BA) frame.    -   167. The method of one or more of clauses 159-162, where        adjusting the one or more parameters of the XR experience        includes adjusting one or more wireless communication parameters        between the device and the second device, where adjusting the        one or more wireless communication parameters includes one or        more of:        -   adjusting a duty cycle of target wake time (TWT) windows of            a TWT power save mode associated with the device and the            second device;        -   enabling or disabling the TWT power save mode;    -   changing a wireless operating channel over which the device and        the second device communicate;        -   adjusting the wireless operating channel size;        -   adjusting a modulation and coding scheme (MCS);        -   enabling or disabling forward error correction (FEC) for            providing at least a portion of the one or more PPDUs to the            second device; or        -   adjusting the FEC for providing at least the portion of the            one or more PPDUs to the second device.    -   168. The method of one or more of clauses 159-161, where an        indication of the adjusted one or more parameters is        communicated between the device and the second device, where the        indication is included in an aggregated control (A-Control)        field of a header of one or more packets communicated between        the device and the second device.    -   169. The method of one or more of clauses 159-161 or 168, where        the A-Control field includes a reserved control identifier (ID)        for the indication.    -   170. The method of one or more of clauses 159-161 or 168, where        the one or more packets are included in one or more of:        -   a request to send (RTS) or clear to send (CTS) frame;        -   a data frame; or        -   a block acknowledgement (BA) frame.    -   171. The method of one or more of clauses 159-170, where        adjusting the one or more parameters of the XR experience        includes adjusting one or more video parameters, where the video        parameters include one or more of:        -   a video frame rate;        -   a video resolution;        -   a target encode data rate; or        -   a video codec.    -   172. The method of one or more of clauses 159-171, where:        -   the device includes a software enabled access point (SAP);            and        -   the second device includes a head mounted display (HMD).    -   173. A device configured for an extended reality (XR)        experience, including:        -   an interface configured to attempt to provide a plurality of            PPDUs associated with one or more video frames of the XR            experience to a second device; and        -   a processing system configured to measure one or more of:            -   a PPDU transmission latency associated with attempting                to provide the plurality of PPDUs; or            -   a PPDU transmission drop associated with attempting to                provide the plurality of PPDUs,            -   where one or more parameters of the XR experience are                adjusted and associated with one or more of the                measurements.    -   174. The device of clause 173, where:        -   the interface is further configured to obtain one or more            pose data frames from the second device, where each of the            one or more video frames is associated with a pose data            frame of the one or more pose data frames; and        -   the processing system is further configured to measure a            pose data frame delivery latency associated with obtaining            the one or more pose data frames.    -   175. The device of one or more of clauses 173-174, where the        processing system is further configured to measure a frequency        of missing or delayed pose data frames associated with obtaining        the one or more pose data frames.    -   176. The device of one or more of clauses 173-175, where the        interface is further configured to provide an indication of the        one or more measurements to the second device in an aggregated        control (A-Control) field of a header of one or more packets        provided to the second device.    -   177. The device of one or more of clauses 173-176, where the        A-Control field includes a reserved control identifier (ID) for        the indication of the one or more measurements.    -   178. The device of one or more of clauses 173-176, where:        -   the one or more measurements include a link quality            measurement of a link quality between the device and the            second device; and        -   the A-Control field includes an indication of the link            quality.    -   179. The device of one or more of clauses 173-176 or 178, where        the A-Control field includes a bit reserved to indicate the link        quality.    -   180. The device of one or more of clauses 173-176, where the one        or more packets are included in one or more of:        -   a request to send (RTS) or clear to send (CTS) frame;        -   a data frame; or        -   a block acknowledgement (BA) frame.    -   181. The device of one or more of clauses 173-176, where        adjusting the one or more parameters of the XR experience        includes adjusting one or more wireless communication parameters        between the device and the second device, where adjusting the        one or more wireless communication parameters includes one or        more of:        -   adjusting a duty cycle of target wake time (TWT) windows of            a TWT power save mode associated with the device and the            second device;        -   enabling or disabling the TWT power save mode;        -   changing a wireless operating channel over which the device            and the second device communicate;        -   adjusting the wireless operating channel size;        -   adjusting a modulation and coding scheme (MCS);        -   enabling or disabling forward error correction (FEC) for            providing at least a portion of the one or more PPDUs to the            second device; or        -   adjusting the FEC for providing at least the portion of the            one or more PPDUs to the second device.    -   182. The device of one or more of clauses 173-175, where an        indication of the adjusted one or more parameters is        communicated between the device and the second device, where the        indication is included in an aggregated control (A-Control)        field of a header of one or more packets communicated between        the device and the second device.    -   183. The device of one or more of clauses 173-175 or 182, where        the A-Control field includes a reserved control identifier (ID)        for the indication.    -   184. The device of one or more of clauses 173-175 or 182, where        the one or more packets are included in one or more of:        -   a request to send (RTS) or clear to send (CTS) frame;        -   a data frame; or        -   a block acknowledgement (BA) frame.    -   185. The device of one or more of clauses 173-184, where        adjusting the one or more parameters of the XR experience        includes adjusting one or more video parameters, where the video        parameters include one or more of:        -   a video frame rate;        -   a video resolution;        -   a target encode data rate; or        -   a video codec.    -   186. The device of one or more of clauses 173-185, where:        -   the device includes a software enabled access point (SAP);            and        -   the second device includes a head mounted display (HMD).    -   187. A method performed by a device, including:        -   attempting to provide a plurality of pose data frames            associated with one or more video frames of an extended            reality (XR) experience to a second device; and        -   measuring one or more of:            -   a pose data frame transmission latency associated with                attempting to provide the plurality of pose data frames;                or            -   a pose data frame transmission drop associated with                attempting to provide the plurality of pose data frames,            -   where one or more parameters of the XR experience are                adjusted and associated with one or more of the                measurements.    -   188. The method of clause 187, further including:        -   obtaining, at a reorder (REO) queue of the device, one or            more media access control layer (MAC) service data units            (MSDUs) from the second device, where each MSDU is            associated with a video slice of the one or more video            frames;        -   flushing the REO queue one or more times to remove one or            more MSDUs from the REO queue; and        -   measuring a REO flush time associated with flushing the REO            queue.    -   189. The method of one or more of clauses 187-188, further        including: for one or more video frames:        -   obtaining a first MSDU associated with a video frame; and        -   obtaining a last MSDU associated with the video frame; and        -   measuring a video frame delivery latency associated with            obtaining the first MSDU and the last MSDU for one or more            video frames.    -   190. The method of one or more of clauses 187-189, where the        first MSDU and the last MSDU are identified by a differentiated        services field codepoint (DSCP) value.    -   191. The method of one or more of clauses 187-190, further        including providing an indication of the one or more        measurements to the second device in an aggregated control        (A-Control) field of a header of one or more packets provided to        the second device.    -   192. The method of one or more of clauses 187-191, where the        A-Control field includes a reserved control identifier (ID) for        the indication of the one or more measurements.    -   193. The method of one or more of clauses 187-191, where:        -   the one or more measurements include a link quality            measurement of a link quality between the device and the            second device; and        -   the A-Control field includes an indication of the link            quality.    -   194. The method of one or more of clauses 187-191 or 193, where        the A-Control field includes a bit reserved to indicate the link        quality.    -   195. The method of one or more of clauses 187-191, where the one        or more packets are included in one or more of:        -   a request to send (RTS) or clear to send (CTS) frame;        -   a data frame; or        -   a block acknowledgement (BA) frame.    -   196. The method of one or more of clauses 187-191, where        adjusting the one or more parameters of the XR experience        includes adjusting one or more wireless communication parameters        between the device and the second device, where adjusting the        one or more wireless communication parameters includes one or        more of:        -   adjusting a duty cycle of target wake time (TWT) windows of            a TWT power save mode associated with the device and the            second device;        -   enabling or disabling the TWT power save mode;        -   changing a wireless operating channel over which the device            and the second device communicate;        -   adjusting the wireless operating channel size;        -   adjusting a modulation and coding scheme (MCS);        -   enabling or disabling forward error correction (FEC) for            providing at least a portion of the one or more PPDUs to the            second device; or        -   adjusting the FEC for providing at least the portion of the            one or more PPDUs to the second device.    -   197. The method of one or more of clauses 187-190, where an        indication of the adjusted one or more parameters is        communicated between the device and the second device, where the        indication is included in an aggregated control (A-Control)        field of a header of one or more packets communicated between        the device and the second device.    -   198. The method of one or more of clauses 187-190 or 197, where        the A-Control field includes a reserved control identifier (ID)        for the indication.    -   199. The method of one or more of clauses 187-190 or 197, where        the one or more packets are included in one or more of:        -   a request to send (RTS) or clear to send (CTS) frame;        -   a data frame; or        -   a block acknowledgement (BA) frame.    -   200. The method of one or more of clauses 187-199, further        including measuring one or more of:        -   a jitter buffer underflow or overflow; or        -   a missing packet associated with a video frame to be            displayed.    -   201. The method of one or more of clauses 187-200, where:        -   the second device includes a software enabled access point            (SAP); and        -   the device includes a head mounted display (HMD).    -   202. A device configured for an extended reality (XR)        experience, including: an interface configured to attempt to        provide a plurality of pose data frames associated with one or        more video frames of the XR experience to a second device; and    -   a processing system configured to measure one or more of:        -   a pose data frame transmission latency associated with            attempting to provide the plurality of pose data frames; or        -   a pose data frame transmission drop associated with            attempting to provide the plurality of pose data frames,        -   where one or more parameters of the XR experience are            adjusted and associated with one or more of the            measurements.    -   203. The device of clause 202, where:        -   the interface is further configured to obtain, at a reorder            (REO) queue of the device, one or more media access control            layer (MAC) service data units (MSDUs) from the second            device, where each MSDU is associated with a video slice of            the one or more video frames; and        -   the processing system is further configured to:            -   flush the REO queue one or more times to remove one or                more MSDUs from the REO queue; and            -   measure a REO flush time associated with flushing the                REO queue.    -   204. The device of one or more of clauses 202-203, where:        -   the interface is further configured to, for one or more            video frames:            -   obtain a first MSDU associated with a video frame; and            -   obtain a last MSDU associated with the video frame; and        -   the processing system is further configured to measure a            video frame delivery latency associated with obtaining the            first MSDU and the last MSDU for one or more video frames.    -   205. The device of one or more of clauses 202-204, where the        first MSDU and the last MSDU are identified by a differentiated        services field codepoint (DSCP) value.    -   206. The device of one or more of clauses 202-205, where the        interface is further configured to provide an indication of the        one or more measurements to the second device in an aggregated        control (A-Control) field of a header of one or more packets        provided to the second device.    -   207. The device of one or more of clauses 202-206, where the        A-Control field includes a reserved control identifier (ID) for        the indication of the one or more measurements.    -   208. The device of one or more of clauses 202-206, where:        -   the one or more measurements include a link quality            measurement of a link quality between the device and the            second device; and        -   the A-Control field includes an indication of the link            quality.    -   209. The device of one or more of clauses 202-206 or 208, where        the A-Control field includes a bit reserved to indicate the link        quality.    -   210. The device of one or more of clauses 202-206, where the one        or more packets are included in one or more of:        -   a request to send (RTS) or clear to send (CTS) frame;        -   a data frame; or        -   a block acknowledgement (BA) frame.    -   211. The device of one or more of clauses 202-206, where        adjusting the one or more parameters of the XR experience        includes adjusting one or more wireless communication parameters        between the device and the second device, where adjusting the        one or more wireless communication parameters includes one or        more of:        -   adjusting a duty cycle of target wake time (TWT) windows of            a TWT power save mode associated with the device and the            second device;        -   enabling or disabling the TWT power save mode;        -   changing a wireless operating channel over which the device            and the second device communicate;        -   adjusting the wireless operating channel size;        -   adjusting a modulation and coding scheme (MCS);        -   enabling or disabling forward error correction (FEC) for            providing at least a portion of the one or more PPDUs to the            second device; or adjusting the FEC for providing at least            the portion of the one or more PPDUs to the second device.    -   212. The device of one or more of clauses 202-205, where an        indication of the adjusted one or more parameters is        communicated between the device and the second device, where the        indication is included in an aggregated control (A-Control)        field of a header of one or more packets communicated between        the device and the second device.    -   213. The device of one or more of clauses 202-205 or 212, where        the A-Control field includes a reserved control identifier (ID)        for the indication.    -   214. The device of one or more of clauses 202-205 or 212, where        the one or more packets are included in one or more of:        -   a request to send (RTS) or clear to send (CTS) frame;        -   a data frame; or        -   a block acknowledgement (BA) frame.    -   215. The device of one or more of clauses 202-214, where the        processing system is further configured to measure one or more        of:        -   a jitter buffer underflow or overflow; or        -   a missing packet associated with a video frame to be            displayed.    -   216. The device of one or more of clauses 202-215, where:        -   the second device includes a software enabled access point            (SAP); and        -   the device includes a head mounted display (HMD).    -   217. A method performed by a wireless communication device,        including: communicating with a first device over a first        wireless link; and communicating with a second device over a        second wireless link, where:        -   the wireless communication device communicates concurrently            with the first device and the second device using one of            multi-link operation (MLO) techniques or a target wake time            (TWT) mode; and        -   the wireless communication device is configured to give            preference to communications on the second wireless link            versus communications on the first wireless link.    -   218. The method of clause 217, where concurrently communicating        with the first device and the second device includes:        -   for when the wireless communication device is to transmit to            the second device during reception of one or more packets            from the first device:            -   transmitting to the second device before the completion                of reception of the one or more packets from the first                device;            -   obtaining a block acknowledgement (BA) from the second                device after transmitting to the second device; and            -   preventing the wireless communication device from                providing a BA to the first device to acknowledge the                reception of the one or more packets.    -   219. The method of clause 217, where concurrently communicating        with the first device and the second device includes:        -   for when the wireless communication device is to obtain one            or more packets from the second device during reception of            one or more packets from the first device:            -   obtaining the one or more packets from the second device                during reception of the one or more packets from the                first device;            -   providing a block acknowledgement (BA) to the second                device after obtaining the one or more packets from the                second device; and            -   preventing the wireless communication device from                providing a BA to the first device to acknowledge the                reception of the one or more packets from the first                device.    -   220. The method of clause 217, where concurrently communicating        with the first device and the second device includes:        -   for when the wireless communication device is to transmit to            the second device during transmission to the first device,            performing one or more of:            -   synchronizing the transmission to the second device with                the transmission to the first device;            -   preventing transmission to the first device outside of                one or more time division multiplexing (TDM) windows,                where:                -   transmission to the first device is during the one                    or more TDM windows; and                -   transmission to the second device is outside of the                    one or more TDM windows;            -   reducing one or more of a maximum physical layer (PHY)                protocol data unit (PPDU) duration or a burst duration;            -   flushing packets from a transmit buffer associated with                the transmission to the first device; or            -   broadcasting a clear to send (CTS) to self (CTS-to-Self)                frame to pad a time period for reserving a wireless                medium, where:                -   the wireless medium includes the first wireless link                    and the second wireless link; and                -   the time period is of sufficient length for the                    transmission to the first device and the                    transmission to the second device.    -   221. The method of one or more of clauses 217 or 220, where        synchronizing the transmission to the second device with the        transmission to the first device includes:        -   synchronizing a start of the transmission to the first            device with a start of the transmission to the second            device; and        -   padding the transmission to the second device to cause an            end of the transmission to the first device to be            synchronized with an end of the transmission to the second            device, where a backoff associated with the second wireless            link is reduced when the transmission to the first device            and the transmission to the second device are synchronized.    -   222. The method of one or more of clauses 217 or 220, where for        when preventing transmission to the first device during a time        division multiplexing window associated with transmission to the        second device, the first device is prevented from supporting a        target wake time (TWT) mode.    -   223. The method of clause 217, where concurrently communicating        with the first device and the second device includes:        -   for when the wireless communication device is to obtain one            or more packets from the second device during transmission            to the first device, performing one or more of:            -   preventing obtaining the one or more packets from the                second device during one or more time division                multiplexing (TDM) windows, where:                -   transmission to the first device is during the one                    or more TDM windows; and                -   reception from the second device is outside of the                    one or more TDM windows;            -   reducing one or more of a maximum physical layer (PHY)                protocol data unit (PPDU) duration or a burst duration;                or            -   before transmitting to the first device, providing a                frame to the second device indicating a network                allocation vector (NAV) value to reserve a wireless                medium for the duration of transmitting to the first                device, where the wireless medium includes the first                wireless link and the second wireless link.    -   224. The method of clause 217, where the communications on the        second wireless link are associated with an extended reality        (XR) experience.    -   225. The method of one or more of clauses 217 or 224, where        concurrently communicating with the first device and the second        device includes:        -   configuring a first target wake time (TWT) session for            communications on the second wireless link, where:            -   the first TWT session is associated with a first                plurality of TWT windows on the second wireless link;            -   the first plurality of TWT windows is associated with XR                activity at the wireless communication device; and            -   the XR activity includes obtaining one or more pose data                frames from the second device, rendering one or more                video frames, and providing the one or more video frames                via one or more physical layer (PHY) protocol data units                (PPDUs) to the second device;        -   configuring a second TWT session for communications on the            first wireless link, where:            -   the second TWT session is associated with a second                plurality of TWT windows interspersed between the first                plurality of TWT windows;            -   the second plurality of TWT windows is associated with                wireless activity between the first device and the                wireless communication device; and            -   the first plurality of TWT windows does not overlap with                the second plurality of TWT windows;        -   communicating with the second device during the first            plurality of TWT windows; and        -   communicating with the first device during the second            plurality of TWT windows.    -   226. The method of one or more of clauses 217, 224, or 225,        further including:        -   measuring a drift between the first plurality of TWT windows            and the second plurality of TWT windows, where:            -   the first TWT session is associated with an application                layer clock associated with the wireless communication                device; and            -   the second TWT session is associated with a wireless                communication device (WCD) clock at a media access                control layer (MAC); and        -   adjusting a timing of one or more of the first plurality of            TWT windows or the second plurality of TWT windows to reduce            the drift.    -   227. The method of one or more of clauses 217 or 224-226, where        the drift is associated with a difference between a fidelity of        the application layer clock and a fidelity of the WCD clock.    -   228. The method of one or more of clauses 217 or 224-226, where        the drift is associated with a difference between a resonance        frequency of the application layer clock and a resonance        frequency of the WCD clock.    -   229. The method of one or more of clauses 217-228, where:        -   the first device is an access point (AP); and        -   the wireless communication device is included in a relay            station (STA) between the AP and the second device.    -   230. The method of one or more of clauses 217-229, where:        -   one or more of the AP or the relay STA is a render device;            and        -   the second device includes a head mounted display (HMD).    -   231. A wireless communication device, including:        -   a processing system; and        -   an interface configured to:            -   communicate with a first device over a first wireless                link; and            -   communicate with a second device over a second wireless                link, where:                -   the wireless communication device communicates                    concurrently with the first device and the second                    device using one of multi-link operation (MLO)                    techniques or a target wake time (TWT) mode; and                -   the wireless communication device is configured to                    give preference to communications on the second                    wireless link versus communications on the first                    wireless link.    -   232. The wireless communication device of clause 231, where        concurrently communicating with the first device and the second        device includes:        -   for when the wireless communication device is to transmit to            the second device during reception of one or more packets            from the first device:            -   transmitting to the second device before the completion                of reception of the one or more packets from the first                device;            -   obtaining a block acknowledgement (BA) from the second                device after transmitting to the second device; and            -   preventing the wireless communication device from                providing a BA to the first device to acknowledge the                reception of the one or more packets.    -   233. The wireless communication device of clause 231, where        concurrently communicating with the first device and the second        device includes:        -   for when the wireless communication device is to obtain one            or more packets from the second device during reception of            one or more packets from the first device:            -   obtaining the one or more packets from the second device                during reception of the one or more packets from the                first device;            -   providing a block acknowledgement (BA) to the second                device after obtaining the one or more packets from the                second device; and            -   preventing the wireless communication device from                providing a BA to the first device to acknowledge the                reception of the one or more packets from the first                device.    -   234. The wireless communication device of clause 231, where        concurrently communicating with the first device and the second        device includes:        -   for when the wireless communication device is to transmit to            the second device during transmission to the first device,            performing one or more of            -   synchronizing the transmission to the second device with                the transmission to the first device;            -   preventing transmission to the first device outside of                one or more time division multiplexing (TDM) windows,                where:                -   transmission to the first device is during the one                    or more TDM windows; and                -   transmission to the second device is outside of the                    one or more TDM windows;            -   reducing one or more of a maximum physical layer (PHY)                protocol data unit (PPDU) duration or a burst duration;            -   flushing packets from a transmit buffer associated with                the transmission to the first device; or            -   broadcasting a clear to send (CTS) to self (CTS-to-Self)                frame to pad a time period for reserving a wireless                medium, where:                -   the wireless medium includes the first wireless link                    and the second wireless link; and                -   the time period is of sufficient length for the                    transmission to the first device and the                    transmission to the second device.    -   235. The wireless communication device of one or more of clauses        231 or 234, where synchronizing the transmission to the second        device with the transmission to the first device includes:        -   synchronizing a start of the transmission to the first            device with a start of the transmission to the second            device; and        -   padding the transmission to the second device to cause an            end of the transmission to the first device to be            synchronized with an end of the transmission to the second            device, where a backoff associated with the second wireless            link is reduced when the transmission to the first device            and the transmission to the second device are synchronized.    -   236. The wireless communication device of one or more of clauses        231 or 234, where for when preventing transmission to the first        device during a time division multiplexing window associated        with transmission to the second device, the first device is        prevented from supporting a target wake time (TWT) mode.    -   237. The wireless communication device of clause 231, where        concurrently communicating with the first device and the second        device includes:        -   for when the wireless communication device is to obtain one            or more packets from the second device during transmission            to the first device, performing one or more of:            -   preventing obtaining the one or more packets from the                second device during one or more time division                multiplexing (TDM) windows, where:                -   transmission to the first device is during the one                    or more TDM windows; and                -   reception from the second device is outside of the                    one or more TDM windows;            -   reducing one or more of a maximum physical layer (PHY)                protocol data unit (PPDU) duration or a burst duration;                or    -   before transmitting to the first device, providing a frame to        the second device indicating a network allocation vector (NAV)        value to reserve a wireless medium for the duration of        transmitting to the first device, where the wireless medium        includes the first wireless link and the second wireless link.    -   238. The wireless communication device of clause 231, where the        communications on the second wireless link are associated with        an extended reality (XR) experience.    -   239. The wireless communication device of one or more of clauses        231 or 238, where concurrently communicating with the first        device and the second device includes:        -   configuring a first target wake time (TWT) session for            communications on the second wireless link, where:            -   the first TWT session is associated with a first                plurality of TWT windows on the second wireless link;            -   the first plurality of TWT windows is associated with XR                activity at the wireless communication device; and            -   the XR activity includes obtaining one or more pose data                frames from the second device, rendering one or more                video frames, and providing the one or more video frames                via one or more physical layer (PHY) protocol data units                (PPDUs) to the second device;        -   configuring a second TWT session for communications on the            first wireless link, where:            -   the second TWT session is associated with a second                plurality of TWT windows interspersed between the first                plurality of TWT windows;            -   the second plurality of TWT windows is associated with                wireless activity between the first device and the                wireless communication device; and            -   the first plurality of TWT windows does not overlap with                the second plurality of TWT windows;        -   communicating with the second device during the first            plurality of TWT windows; and        -   communicating with the first device during the second            plurality of TWT windows.    -   240. The wireless communication device of one or more of clauses        231, 238, or 239, where the processing system is configured to:        -   measure a drift between the first plurality of TWT windows            and the second plurality of TWT windows, where:            -   the first TWT session is associated with an application                layer clock associated with the wireless communication                device; and            -   the second TWT session is associated with a wireless                communication device (WCD) clock at a media access                control layer (MAC); and        -   adjust a timing of one or more of the first plurality of TWT            windows or the second plurality of TWT windows to reduce the            drift.    -   241. The wireless communication device of one or more of clauses        231 or 238-240, where the drift is associated with a difference        between a fidelity of the application layer clock and a fidelity        of the WCD clock.    -   242. The wireless communication device of one or more of clauses        231 or 238-240, where the drift is associated with a difference        between a resonance frequency of the application layer clock and        a resonance frequency of the WCD clock.    -   243. The wireless communication device of one or more of clauses        231-242, where:        -   the first device is an access point (AP); and        -   the wireless communication device is included in a relay            station (STA) between the AP and the second device.    -   244. The wireless communication device of one or more of clauses        231-243, where:        -   one or more of the AP or the relay STA is a render device;            and        -   the second device includes a head mounted display (HMD).

As used herein, a phrase referring to “at least one of” or “one or moreof” a list of items refers to any combination of those items, includingsingle members. For example, “at least one of: a, b, or c” is intendedto cover the possibilities of: a only, b only, c only, a combination ofa and b, a combination of a and c, a combination of b and c, and acombination of a and b and c.

The various illustrative components, logic, logical blocks, modules,circuits, operations, and algorithm processes described in connectionwith the implementations disclosed herein may be implemented aselectronic hardware, firmware, software, or combinations of hardware,firmware, or software, including the structures disclosed in thisspecification and the structural equivalents thereof. Theinterchangeability of hardware, firmware and software has been describedgenerally, in terms of functionality, and illustrated in the variousillustrative components, blocks, modules, circuits and processesdescribed above. Whether such functionality is implemented in hardware,firmware or software depends upon the particular application and designconstraints imposed on the overall system.

Various modifications to the implementations described in thisdisclosure may be readily apparent to persons having ordinary skill inthe art, and the generic principles defined herein may be applied toother implementations without departing from the spirit or scope of thisdisclosure. Thus, the claims are not intended to be limited to theimplementations shown herein, but are to be accorded the widest scopeconsistent with this disclosure, the principles and the novel featuresdisclosed herein.

Additionally, various features that are described in this specificationin the context of separate implementations also can be implemented incombination in a single implementation. Conversely, various featuresthat are described in the context of a single implementation also can beimplemented in multiple implementations separately or in any suitablesubcombination. As such, although features may be described above asacting in particular combinations, and even initially claimed as such,one or more features from a claimed combination can in some cases beexcised from the combination, and the claimed combination may bedirected to a subcombination or variation of a subcombination.

Similarly, while operations are depicted in the drawings in a particularorder, this should not be understood as requiring that such operationsbe performed in the particular order shown or in sequential order, orthat all illustrated operations be performed, to achieve desirableresults. Further, the drawings may schematically depict one more exampleprocesses in the form of a flowchart or flow diagram. However, otheroperations that are not depicted can be incorporated in the exampleprocesses that are schematically illustrated. For example, one or moreadditional operations can be performed before, after, simultaneously, orbetween any of the illustrated operations. In some circumstances,multitasking and parallel processing may be advantageous. Moreover, theseparation of various system components in the implementations describedabove should not be understood as requiring such separation in allimplementations, and it should be understood that the described programcomponents and systems can generally be integrated together in a singlesoftware product or packaged into multiple software products.

1. A method performed by a device, comprising: rendering a plurality offrames to be provided to a second device; splitting each frame of theplurality of frames into a plurality of application files; and for eachapplication file of the plurality of application files: generating aplurality of physical layer convergence protocol (PLCP) protocol dataunits (PPDUs) to include the application file, wherein: each PPDUincludes one or more media access control layer (MAC) service data units(MSDUs) associated with the application file; and the application fileis identified by a port number and a differentiated services fieldcodepoint (DSCP) value included in each MSDU of the plurality of PPDUs;and queuing the MSDUs for transmission to the second device.
 2. Themethod of claim 1, wherein queuing the MSDUs includes generating an MSDUqueue in software for each application file, wherein each MSDU queue isidentified by an internet protocol (IP) address, port number, and DSCPvalue.
 3. The method of claim 2, wherein each application file isassociated with a traffic identifier (TID) that is associated with anaccess category (AC) of the application file.
 4. The method of claim 3,wherein the AC of the application file is associated with a priority ofthe application file, and wherein the priority of the application filedepends on whether the application file is a i-slice or a p-slice. 5.(canceled)
 6. The method of claim 4, further comprising: rendering afirst p-slice; generating a first MSDU queue associated with the firstp-slice; rendering a second p-slice after rendering the first p-slice;and flushing the first MSDU queue after rendering the second p-slice andbefore providing, to the second device, a PPDU including one or moreMSDUs associated with the first p-slice.
 7. The method of claim 4,further comprising: rendering a first i-slice; generating a first MSDUqueue associated with the first i-slice; rendering a second i-slice orp-slice after rendering the first i-slice; generating a second MSDUqueue associated with the second i-slice; and providing, to the seconddevice, a PPDU including one or more MSDUs associated with the firsti-slice after generating the second MSDU queue.
 8. The method of claim4, wherein for an MSDU associated with the application file: the MSDU isattempted to be transmitted to the second device up to a thresholdnumber of times; and the device flushes an MSDU queue associated withthe application file after unsuccessfully attempting to transmit theMSDU to the second device the threshold number of times. 9-13.(canceled)
 14. A device configured for an extended reality (XR)experience, comprising: an interface; and a processing system thatincludes one or more processors and one or more memories coupled withthe one or more processors, the processing system configured to: rendera plurality of frames to be provided to a second device; split eachframe of the plurality of frames into a plurality of application files;and for each application file of the plurality of application files:generate a plurality of physical layer convergence protocol (PLCP)protocol data units (PPDUs) to include the application file, wherein:each PPDU includes one or more media access control layer (MAC) servicedata units (MSDUs) associated with the application file; and theapplication file is identified by a port number and a differentiatedservices field codepoint (DSCP) value included in each MSDU of theplurality of PPDUs; and queue the MSDUs for transmission to the seconddevice.
 15. The device of claim 14, wherein queuing the MSDUs includesgenerating an MSDU queue in software for each application file, whereineach MSDU queue is identified by an internet protocol (IP) address, portnumber, and DSCP value.
 16. The device of claim 15, wherein eachapplication file is associated with a traffic identifier (TID) that isassociated with an access category (AC) of the application file.
 17. Thedevice of claim 16, wherein the AC of the application file is associatedwith a priority of the application file.
 18. The device of claim 17,wherein the priority of the application file depends on whether theapplication file is a i-slice or a p-slice.
 19. The device of claim 18,wherein the processing system is further configured to: render a firstp-slice; generate a first MSDU queue associated with the first p-slice;render a second p-slice after rendering the first p-slice; and flush thefirst MSDU queue after rendering the second p-slice and beforeproviding, to the second device, a PPDU including one or more MSDUsassociated with the first p-slice.
 20. The device of claim 18, wherein:the processing system is further configured to: render a first i-slice;generate a first MSDU queue associated with the first i-slice; render asecond i-slice or p-slice after rendering the first i-slice; andgenerate a second MSDU queue associated with the second i-slice; and theinterface is configured to provide, to the second device, a PPDUincluding one or more MSDUs associated with the first i-slice aftergenerating the second MSDU queue.
 21. The device of claim 18, whereinfor an MSDU associated with the application file: the interface isconfigured to attempt to transmit the MSDU to the second device up to athreshold number of times; and the processing system is furtherconfigured to flush an MSDU queue associated with the application fileafter unsuccessfully attempting to transmit the MSDU to the seconddevice the threshold number of times.
 22. The device of claim 21,wherein the processing system is further configured to: generate areplacement application file after flushing the MSDU queue; and generatea replacement MSDU queue associated with the replacement applicationfile.
 23. The device of claim 21, wherein the interface is furtherconfigured to indicate, to the second device, that the MSDU queue isflushed.
 24. The device of claim 14, wherein the device is configured touse forward error correction (FEC) for transmitting one or more PPDUs tothe second device.
 25. The device of claim 24, wherein use of FEC fortransmitting one or more PPDUs to the second device is associated withone or more of: a link quality between the device and the second device;one or more parameters of the second device; or one or more parametersof the plurality of frames.
 26. The device of claim 14, wherein: thedevice includes a software enabled access point (SAP); and the seconddevice includes a head mounted display (HMD).
 27. A method performed bya device, comprising: obtaining, from a second device, one or morephysical layer convergence protocol (PLCP) protocol data units (PPDUs)associated with an application file, wherein: a plurality of PPDUsinclude the application file, each PPDU including one or more mediaaccess control layer (MAC) service data units (MSDUs) associated withthe application file and the application file being identified by a portnumber and a differentiated services field codepoint (DSCP) valueincluded in each MSDU of the plurality of PPDUs; obtaining, at a reorder(REO) queue of the device, one or more MSDUs associated with theapplication file from the second device; and flushing the REO queue inaccordance with not obtaining a remainder of MSDUs associated with theapplication file before a REO timeout occurs or an indication that atransmit queue associated with the one or more MSDUs is flushed by thesecond device.
 28. The method of claim 27, further comprising:obtaining, at the REO queue of the device, a portion of MSDUs associatedwith the application file, the portion of MSDUs including the one ormore MSDUs; and flushing the REO queue after not obtaining the remainderof MSDUs associated with the application file before the REO timeoutoccurs.
 29. The method of claim 27, further comprising: obtaining theindication that the transmit queue associated with the one or more MSDUsis flushed by the second device; and flushing the REO queue afterobtaining the indication.
 30. A device configured for an extendedreality (XR) experience, including: an interface configured to: obtain,from a second device, one or more physical layer convergence protocol(PLCP) protocol data units (PPDUs) associated with an application file,wherein: a plurality of PPDUs include the application file, each PPDUincluding one or more media access control layer (MAC) service dataunits (MSDUs) associated with the application file and the applicationfile being identified by a port number and a differentiated servicesfield codepoint (DSCP) value included in each MSDU of the plurality ofPPDUs; and obtain, at a reorder (REO) queue of the device, one or moreMSDUs associated with the application file from the second device; and aprocessing system that includes one or more processors and one or morememories coupled with the one or more processors, the processing systemconfigured to: flush the REO queue in accordance with not obtaining aremainder of MSDUs associated with the application file before a REOtimeout occurs or an indication that a transmit queue associated withthe one or more MSDUs is flushed by the second device.
 31. The device ofclaim 30, wherein: the interface is further configured to obtain, at theREO queue of the device, a portion of MSDUs associated with theapplication file, the portion of MSDUs including the one or more MSDUs;and the processing system is configured to flush the REO queue after notobtaining the remainder of MSDUs associated with the application filebefore the REO timeout occurs.
 32. The device of claim 31, wherein theREO timeout is associated with an access category (AC) of theapplication file.
 33. The device of claim 30, wherein: the interface isfurther configured to obtain the indication that the transmit queueassociated with the one or more MSDUs is flushed by the second device;and the processing system is configured to flush the REO queue afterobtaining the indication.
 34. The device of claim 30, wherein the deviceis configured to use forward error correction (FEC) for obtaining one ormore PPDUs from the second device.
 35. The device of claim 34, whereinuse of the FEC for obtaining one or more PPDUs from the second device isassociated with one or more of: a link quality between the device andthe second device; one or more parameters of the second device; or oneor more parameters of a plurality of application files including theapplication file.
 36. The device of claim 35, wherein: the second deviceincludes a software enabled access point (SAP); and the device includesa head mounted display (HMD).